臺灣高等法院 93 年重上字第 119 號民事判決

臺灣高等法院民事判決 93年度重上字第119號上 訴 人 臺灣銀行股份有限公司法定代理人 張明道訴訟代理人 劉景榮複代理人 林雅芬律師

周廷翰律師陳鵬光律師吳典倫律師備位上訴人 交通部民用航空局法定代理人 尹承蓬訴訟代理人 林雅芬律師

周廷翰律師陳鵬光律師吳典倫律師被上訴人 香港商洛克希德飛機國際有限公司法定代理人 LESTER W. SCHIEFELBEIN,JR被上訴人 洛克希德馬汀股份有限公司法定代理人 LILIAN M. TRIPPETT共 同訴訟代理人 陳長文律師

李念祖律師馮博生律師複 代理人 林耀琳律師

楊東晏律師林鈺珊律師上列當事人間請求返還價金等事件，上訴人對於中華民國92年8月20日臺灣臺北地方法院78年度重訴字第251號第一審判決提起上訴，本院於中華民國100年8月30日言詞辯論終結，判決如下：

主 文原判決關於駁回上訴人臺灣銀行股份有限公司後開第二項之訴部分，及該部分假執行之聲請，與訴訟費用之裁判均廢棄。

被上訴人應連帶給付上訴人臺灣銀行股份有限公司美金玖佰伍拾陸萬叁仟陸佰肆拾陸元捌角陸分、新台幣肆仟壹佰柒拾萬陸仟肆佰肆拾肆元，及被上訴人香港商洛克希德飛機國際有限公司自民國七十八年八月十一日起、被上訴人洛克希德馬汀股份有限公司自民國七十九年二月二十八日起，均至清償日止按年息百分之五計算之利息。

其餘上訴駁回。

第一、二審訴訟費用由被上訴人連帶負擔二分之一，餘由上訴人臺灣銀行股份有限公司負擔。

本判決命被上訴人給付部分，於上訴人臺灣銀行股份有限公司以美金叁佰壹拾捌萬柒仟捌佰捌拾貳元及新台幣壹仟叁佰玖拾萬貳仟壹佰肆拾柒元為被上訴人預供擔保後得假執行，但被上訴人如以美金玖佰伍拾陸萬叁仟陸佰肆拾陸元捌角陸分及新台幣肆仟壹佰柒拾萬陸仟肆佰肆拾肆元為上訴人臺灣銀行股份有限公司預供擔保，得免為假執行。

事實與理由

甲、程序方面：

一、本件原上訴人中央信託局股份有限公司（下稱中信局），於民國（下同）96年7月1日與臺灣銀行股份有限公司（下稱臺灣銀行）合併，並以中信局為消滅公司，臺灣銀行為存續公司，由臺灣銀行概括承受中信局全部之營業及資產與負債，有行政院金融監督管理委員95年12月22日金管銀㈡字第09500534260號函附卷可稽（見本院卷五第283至284頁)，則臺灣銀行聲明承受訴訟，核無不合。又臺灣銀行之總經理嗣於98年7月22日由羅澤成變更為蔡富吉， 嗣又於99年1月8日由蔡富吉變更為張明道，有臺灣銀行98年7月22日銀人資字第09800335891號函，及財政部98年12月31日台財人字第09800665750號函在卷足憑（見本院卷九第37頁、卷十一第12頁)，則蔡富吉、張明道相繼聲明承受訴訟，亦無不合。另本件備位上訴人交通部民用航空局（以下稱民航局）之法定代理人已於97年7月16日由張國政變更為李龍文，嗣又於99年7月16日由李龍文變更為尹承蓬， 有行政院97年7月14日院授人力字第0970062739號函，及行政院99年7月12日院授人力字第0990063377號令在卷足稽（見本院卷六第3頁、卷十四第138頁)，則李龍文、尹承蓬相繼聲明承受訴訟，核無不合，先予敘明。

二、按依香港澳門關係條例第38條前段：「民事事件涉及香港或澳門者，類推適用涉外民事法律適用法。涉外民事法律適用法未規定者，適用與民事法律關係最重大牽連關係地法律。

」，香港澳門關係條例第38條前段定有明文。又按「法律行為發生債之關係者，其成立要件及效力，依當事人意思定其應適用之法律；當事人意思不明時，同國籍者依其本國法，國籍不同者依行為地法，行為地不同者以發要約通知地為行為地。」 ，涉外民事法律適用法第6條第1項、第2項前段亦有明文。本件上訴人臺灣銀行係依中華民國法律成立之法人，備位上訴人民航局係中華民國政府機關，被上訴人香港商洛克希德飛機國際有限公司（以下稱洛克希德飛機公司）為依香港法律成立之公司、被上訴人洛克希德馬汀股份有限公司（以下稱洛克希德馬汀公司）為依美國法律成立之公司，兩造國籍不同，要屬涉外事件。而兩造「中央信託局購料處國外採購合約條款（Conditions of Contract）」（以下稱CTC條款）第28條約定「Any dispute of whatever naturearising out of or, in any way, relating to the Con-tract or to its construction or fulfilment may bereferred to arbitration or lawsuit.……In the event

of lawsuit, it shall also take place in Taipei under

the sole and exclusive jurisdiction of Taipei Distr-

ict Court, Republic of China.Whatever the case maybe, the laws of the Republic of China shall govern.（因履行合約引起之一切爭端，不論其性質為何，俱可訴諸仲裁或訴訟，仲裁，應在中華民國台北市，並按中華民國商務仲裁條例辦理；訴訟，概受中華民國台北地方法院管轄，並依中華民國法律辦理）」（見外放合約文件㈠第B6-82頁），是本件上訴人依兩造契約請求被上訴人為金錢之給付，自應以我國法律為準據法。

三、按訴狀送達後，原告不得將原訴變更或追加，但請求之基礎事實同一，不甚礙被告之防禦及訴訟之終結者，不在此限，民事訴訟法第255條第1項第2款、第7款定有明文。所謂請求之基礎事實同一，係指變更或追加之訴與原訴之主張爭點有其共同性，各請求利益之主張在社會上可認為同一或關連，而就原請求之訴訟及證據資料，於審理繼續進行在相當程度範圍內具有同一性或一體性，得期待於後請求之審理予以利用，俾先後兩者請求在同一程序加以解決，避免重複審理，進而為統一解決紛爭者，即屬之。本件上訴人於原審依兩造間系爭航管自動化系統採購契約，以洛克希德飛機公司為被告，請求返還已付價金、遲延罰款及賠償違約之損害，嗣於78年8月9日基於同一採購契約，追加洛克希德電子公司為被告，請求洛克希德電子公司應與洛克希德飛機公司負連帶給付責任（見原審卷一第28頁），核屬基於同一基礎事實所追加，且上訴人係於訴訟之初原審第一次辯論期日前即為訴之追加，亦不甚礙被上訴人之防禦及訴訟之終結，依民事訴訟法第255條第1項第2款、第7款規定，自為法之所許。且按法院因民事訴訟法第255條第1項但書規定，而許訴之變更或追加，或以訴為非變更或無追加之裁判，不得聲明不服。民事訴訟法第258條第1項定有明文。本件原審業依民事訴訟法第255條第2款規定，准上訴人追加洛克希德電子公司為被告（見原審判決書第22頁），則依上開規定，被上訴人應不得聲明不服，則其於本院再為爭執，自無可取。

四、又按主觀的預備訴之合併，縱其先、備位之訴之訴訟標的容或不同，然二者在訴訟上所據之基礎事實如屬同一，攻擊防禦方法即相互為用，而不致遲滯訴訟程序之進行。苟於備位訴訟之當事人未拒卻而應訴之情形下，既符民事訴訟法所採辯論主義之立法精神，並可避免裁判兩歧，兼收訴訟經濟之效，自為法之所許(最高法院94年度台抗字第980號判決意旨參照）。又原告多數之主觀預備合併，如先、備位原告之主張在實質上、經濟上具有同一性，並得因任一原告勝訴而達訴訟之目的，或在無礙於對造防禦而生訴訟不安定或在對造甘受此「攻防對象擴散」之不利益情形時，為求訴訟經濟、防止裁判矛盾、發見真實、擴大解決紛爭、避免訴訟延滯及程序法上之紛爭一次解決，並從訴訟為集團之現象暨主觀預備合併本質上乃法院就原告先、備位之訴定其審判順序及基於辯論主義之精神以觀，自非不得合併提起（最高法院94年度台上字第283號、 94年度台上字第1078號判決、90年度台抗字第537號裁定要旨參照)。本件上訴人以洛克希德電子公司及被上訴人洛克希德飛機公司因人員、能力等因素，履行系爭航管契約之進度嚴重落後，上訴人已於催告後解除全部契約之同一基礎事實，提起主觀預備合併之訴，先位之訴主張合併前中信局為契約當事人，請求被上訴人返還已付價金、遲延罰款及違約損害之賠償，為免法院審理結果，認民航局為契約當事人，而中信局非系爭航管契約之當事人，乃以民航局為備位原告請求被上訴人為同一之給付，先、備位上訴人協同定其順序起訴，其備位上訴人地位之不安定，乃其預先評估自願承擔，其主張之基礎事實及理由均同一，所委任之訴訟代理人亦相同，顯見先後位上訴人之地位，在實質上並不相衝突對立，其併同提起可達訴訟經濟、避免裁判兩岐，擴大解決紛爭。就被上訴人而言，因先備位上訴人所據之事實理由相同，並不因先備位上訴人之不同，妨礙被上訴人之攻擊防禦。且先備位上訴人所據之基礎事實同一，其主張在實質上、經濟上具有同一性，其攻擊防禦方法相互為用，並得因任一上訴人勝訴而達訴訟之目的，不致遲滯訴訟程序之進行，而影響訴訟之終結。為求訴訟之經濟、紛爭之一次解決，並避免裁判矛盾，及基於上訴人依處分權主義有權決定審判及對象與順序，並有受適時審判之權利，且訴訟指揮之行使應顧慮公正程序請求權之保護，上訴人提起本件主觀預備合併之訴，應為法之所許。

乙、實體方面：

壹、本件上訴人起訴主張：原上訴人中信局於72年間，受備位上訴人民航局之委託公開比價採購「航管自動化系統」，由被上訴人洛克希德馬汀公司合併前之洛克希德電子公司於72年11月10日以美金3906萬2649元得標，其中美金付款部分為3155萬1914元，新台幣付款部分為3億223萬2000元，嗣於75年8月30日為因應我國新制營業稅之實施， 乃將新台幣付款部分減為2億9684萬5974元，復於76年9月10日調整增加美金付款部分為3166萬7184元。上開航管自動化系統採購合約於72年12月20日由洛克希德飛機公司與中信局簽訂，並依合約闡明條款第22條之約定，洛克希德電子公司亦成為合約當事人，與中信局同時簽訂上開合約。至美商洛克希德公司則另行發函表示同意擔任系爭合約之保證人。又系爭合約所採購之航管自動化系統，項目大別可分為航路自動化系統（簡稱TACC）及三個終端自動化系統(簡稱TCC，即中正、高雄及台中三地機場之塔台及近場管制系統）。締約當時雙方約定之交貨日期為：１、航路自動化系統應於75年4月5日；２、中正終端自動化系統應於76年8月5日；３、高雄終端自動化系統應於77年2月5日；４、台中終端自動化系統應於77年8月5日前交貨。嗣於74年8月8日，雙方再訂立合約第四號修正書，變更交貨日期為如下： １、航路自動化系統為76年8月30日以前（延後）；２、中正終端自動化系統為76年11月30日以前(延後)；３、高雄終端自動化系統77年2月29日以前(延後）；４、台中終端自動化系統為77年5月30日以前（提前)。

惟洛克希德電子公司及被上訴人洛克希德飛機公司因本身人員、能力等因素，遲至76年底連第一階段航路自動化系統均無法交貨，而整個契約預定進度全部嚴重落後，民航局乃於76年12月1日，依合約闡明條款第5.3.1條之規定，催告彼等於60天內補正遲延之給付，被上訴人洛克希德飛機公司接獲原告之補正催告函後，僅於77年1月15日向民航局提出 「完工計劃」，並未作出任何遲延給付之補正，民航局遂於77年6月25日正式通知解除全部契約等情 ，爰依回復原狀請求權、系爭合約書第10條 、民法第227條、不當得利、無因管理、民法第250條 ，第231條、233條、259條、第260條及侵權行為之法則，暨連帶保證關係，先位求為命被上訴人連帶給付上訴人中信局（台灣銀行）如原判決附表一、二所示之本金及利息之判決；如認中信局並非系爭合約之買方當事人，自得以系爭合約買方當事人，本於相同於中信局上開之主張事實及法律暨合約依據，備位求為命被上訴人連帶給付備位上訴人民航局如原判決附表一、二所示之本金及利息之判決。

貳、被上訴人則以：系爭合約關係僅存在於中信局（台灣銀行）與被上訴人洛克希德飛機公司間，洛克希德電子公司並非合約當事人，又系爭工程縱有給付遲延之情事，亦屬可歸責於民航局之事由所致， 被上訴人有系爭合約條款闡明第4.2條所定可宥恕事由，故並無給付遲延責任。況本件上訴人並未依合約條款闡明第5.3.1條規定， 催告洛克希德電子公司補正，僅向被上訴人洛克希德飛機公司為通知，並不發生催告效力，惟洛克希德電子公司仍已提出完工計劃書，為適當之補救措施，故先備位上訴人表示終止合約，充其量僅能視為系爭合約條款闡明第5.2條所規定之任意終止情形， 而此種終止合約之效果，並無使先備位上訴人取得返還價金、遲延罰款及損害賠償之請求權等語，資為抗辯。

參、原審判決駁回上訴人先位及備位之訴及其假執行之聲請，上訴人不服提起上訴，其上訴聲明為：㈠先位聲明： 1、原判決廢棄。 2、被上訴人應連帶給付上訴人中信局（台灣銀行）如原判決附表一及附表二所示之本金及利息。 3、願供擔保請准宣告假執行。 4、第一、二審訴訟費用由被上訴人連帶負擔。㈡備位聲明：1、原判決廢棄。2、被上訴人應連帶給付備位上訴人民航局如原判決附表一及附表二所示之本金及利息。3、願供擔保請准宣告假執行。4、第一、二審訴訟費用由被上訴人連帶負擔。被上訴人答辯聲明為：上訴駁回，第二審訴訟費用由上訴人負擔。

肆、本件經依民事訴訟法第463條準用同法第270條之1第1項第3款規定，整理兩造不爭執事項並協議簡化爭點，兩造同意就本院99年3月26日準備程序中， 兩造協議簡化之爭點為辯論範圍（見本院卷十一第150至151頁）。兩造不爭執事項及爭點為：

一、兩造不爭執事項：

（一）中信局於72年間受民航局之委託公開比價採購「航管自動化系統」，由被上訴人洛克希德馬汀公司合併前之洛克希德電子公司於72年11月10日以美金3906萬2649元得標，並於72年12月20日由中信局與洛克希德飛機公司簽訂系爭航管自動化系統合約，約定以「whole lot; turn key」 方式採購航管自動化系統，包括台北區管制中心自動化系統（以下稱TACC），及台北、台中、高雄三個終端管制中心自動化系統（以下稱台北TCC系統、台中TCC系統、高雄TCC系統）。 並約定完工期限為：㈠TACC系統為75年4月5日、㈡台北TCC系統為76年8月5日、 ㈢高雄TCC系統為77年2月5日、㈣台中TCC系統為77年8月5日。被上訴人洛克希德馬汀公司合併前之美商洛克希德公司則於72年12月13日出具保證書，表示同意按保證書內容負保證責任。

（二）系爭契約於簽訂後，迭經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日第六次修正時，將契約總價修正為美金3904萬4071元，其中美金付款部分為美金3166萬7184元 ，新台幣付款部分為新台幣2億9684萬5974元。

（三）中信局於 76年12月1日以洛克希德飛機公司未遵守契約期限，顯可預見系爭航管工程無法如期完工為由，通知洛克希德飛機公司「The CTC/CAA hereby notifies Lockheed

of its intent to terminate the reference contract

in accordance with section 5.3.1 of the contract,unless appropriate action to cure such failure.including the provision of an affirmative projectrecovery plan satisfactory to CTC/CAA,shall havebeen taken within 60 days after thereceipt of thisnotice.」。洛克希德飛機公司於77年1月15日檢附「完工計劃」函覆中信局，中信局嗣於77年6月25日發函通知洛克希德飛機公司稱「……Unfortunately, our client,Civil Aeronautics Administration, advised thisoffice that these contractual obligations have notbeen completed by your esteemed firm and this of-fice have no other choice but to terminate thewhole contract pursuant to article 5.3.1 of theClarifications to contract terms and condition andrecord the case as a default on your part.」，並先後於77年7月28日、77年8月16日通知洛克希德飛機公司所委託之信孚銀行給付履約保證金美金210萬2866元及預付款保證金美金238萬1061元。

（四）洛克希德電子公司於79年間與洛克希德山得公司合併，以洛克希德山得公司為存續公司，洛克希德山得公司於85年間與美商洛克希德公司合併，以美商洛克希德公司為存續公司，美商洛克希德公司再與洛克希德馬汀公司合併，以洛克希德馬汀公司為存續公司。被上訴人洛克希德馬汀公司因合併而承受洛克希德電子公司之一切權利義務及美商洛克希德公司之保證責任。

二、兩造爭點：

（一）上訴人民航局及洛克希德電子公司是否亦為本件契約之當事人？

（二）上訴人於原審所提主觀預備合併之訴，是否合法？

（三）上訴人於原審追加洛克希德電子公司為被告，是否合法？

（四）就系爭契約價金之返還、遲延罰款及損害賠償，洛克希德馬汀公司應否與洛克希德飛機公司負連帶責任？

（五）系爭契約之性質為何？

（六）國立成功大學航空太空工程研究所（以下稱成大航太系所）及國防部軍備局中山科學研究院（以下稱中科院）鑑定報告於本件有無證據能力？

（七）上訴人有無要求洛克希德飛機公司、洛克希德電子公司（以下合稱洛克希德公司）提供約外之設備、服務或功能需求？被上訴人未能於期限內交付「航管自動化系統」，有無闡明條款第4.2條所定之可宥恕情形？

（八）上訴人如有提出約外要求，完工交付時程應依闡明條款第

4.1條為如何之調整？ 被上訴人未能於期限內交付「航管自動化系統」，如有可宥恕情形，完工時程應順延之日數？

（九）洛克希德飛機公司提出之完工計畫是否可認已為適當之補救？

（十）中信局可否依闡明條款第5.3.1.a條terminate系爭契約？中信局於76年12月1日發函催告及於77年6月25日發函依闡明條款第5.3.1.條「terminate」 系爭契約是否合法有效？

（）如為有效，中信局依闡明條款第5.3.1.a條terminate契約之法律效果為契約解除或終止？ 契約terminate後，依照契約規定，雙方權利義務關係如何？系爭契約條款有無排除或優先於民法相關規定之適用？

（）如中信局不得依闡明條款第5.3.1.a條terminate契約，則雙方權義關係如何？

（）上訴人可否依民法第259條、第179條及系爭契約之國外採購契約條款第20條規定，請求被上訴人返還已付之價金及原判決附表二所示之利息？及其數額？

（）上訴人可否依民法第250條及系爭契約闡明條款第10條規定，請求被上訴人給付遲延罰款？及其數額？可否免除、減輕或酌減？

（）上訴人可否依民法第227條、第231條、第233條、第179條、第184條、第176條，及國外採購契約條款第20條規定，請求被上訴人賠償其所支付之關稅、信用狀保證及簽證費？及其數額？

伍、上開爭點，除「上訴人提起主觀預備合併之訴是否合法」及「上訴人於原審追加洛克希德電子公司為被告是否合法」之爭點，已於程序部分敘明外，茲就其餘爭點析述本院得心證之理由如下：

一、上訴人民航局及洛克希德電子公司是否為本件契約之當事人？

（一）民航局是否為本件契約之當事人？

１、查中信局於72年間受民航局之委託公開比價採購「航管自動化系統」，由被上訴人洛克希德馬汀公司合併前之洛克希德電子公司於72年11月10日以美金3906萬2649元得標，並於72年12月20日由中信局與洛克希德飛機公司簽訂系爭航管自動化系統合約，為兩造不爭之事實。而系爭契約「ORIGINAL (FORM B)INVITATION BID & CONTRACT」（以下稱FORM B），其「BID」欄所載提出要約者為「LockheedAircraft Int'l Ltd」即洛克希德飛機公司，而於「CON-TRACT」欄為承諾者為「CENTRAL TRUST OF CHINA」 即中信局（見外放中信局合約卷夾第1頁）， 又系爭契約前後六度修正，均僅由中信局簽署（見原審卷二第157至164頁），且洛克希德飛機公司開立之INVOICE亦均載明「SOLD

TO:Central Trust of China」 ，並由中信局付款，有洛克希德飛機公司開立之INVOICE 及中信局購料處付款之簡便行文表在卷可稽（見本院卷十一第44至97頁），上訴人主張中信局為系爭契約之買方當事人，尚非無據。

２、被上訴人雖以FORM B開宗明義記載 「Central Trust ofChina Procurement Department……on behalf of theclient Civil Aeronantics Adm.,……」， 而所謂「onbehalf of」 依遠東英漢大辭典之解釋，係指代理或代表他人之意，主張中信局係代理民航局簽訂系爭航管契約云云，惟查「on behalf of」遠東英漢大辭典雖解為「作…之代表」（見原審卷四第27頁），但此並非唯一之解釋，法律辭典「Black's Law Dictionary」則將 「on behalfof」譯為「為某人之利益」 （見原審原證卷一第169頁），國立台灣大學法律學系於73年間就同類契約，亦出具意見函表示「貴局上開附件英文契約，……其首三行「CENTRAL TRUST OF CHINA……ON BEHALF OF THE CLIENT……』固說明貴局係代……辦理招標事宜，但ON BEHALFOF字樣似尚不足即據以認定貴局係……之代理人。蓋我國民法上代理有其特定之法律意義」，有該學系73年11月14日函附卷可按（見原審原證卷一第214頁）， 是不能逕以系爭契約FORM B首3行之記載， 而認系爭契約為中信局係代理民航局簽訂。而按代理為對外關係，代理人必須以本人名義與第三人為法律行為，其法律效果始直接對於本人發生效力（最高法院80年台上字第2164號判決意旨參照），本件契約FORM B前言雖載「ON BEHALF OF THE CLIENT」，但於末尾簽署時並未表明代理之旨，且契約之招標係由中信局依其投標須知所訂之程序、規則辦理（見外放中信局購料處合約卷夾第76、77頁），契約招標文件中的「Supplemental Porcurement Documentation」（輔助採購文件）第4.75.1條「Contracting Officer」 亦載明締約者為中信局（見外放證物），均未表明其係以民航局之代理人身分為之，上訴人主張契約首3行不過在說明中信局與民航局之內部關係，該on behalf of僅係「為某人之利益」或「為某人之計算」之意，尚堪信取。被上訴人主張中信局僅係代理民航局簽訂系爭航管契約，非系爭航管契約之當事人云云，應無可取。

３、又民航局之代表雖僅於契約FROM B上「Opening of bidswitnessed by」之「Client」處簽名，惟本件契約招標之各項文件「Supplemental Procurement Documentation

for the Taipei Area Control Center and TerminalControl Center Automation Systems」、「Instruc-tions for Preparation of Proposal for the Terminal

Control Center Automation System」、「Statement

of Work for the Aera and Terminal Control CenterAutomation System」等，均以中英文載明「中華民國民用航空局」、「Civil Aeronautics AdministrationMinistry of Communications Republic of China」，並於「ABSTRACT」載明「The Civil Aeronautics Adminis-tration of The Republic of China has undertaken aprogram to upgrade its air traffic services. Afacet to this program consists of the automation

of the Terminal and Area Contral Centers. The pur-pose of this document is to provide notes and in-formation for offerors, and a summary of Evalua-tion factors to be used in the automation systemprocurement.」（見外放契約招標文件）均已表明實際需求者為民航局，系爭契約之工程招標需求Request forProposal（簡稱REP）及契約附件之「Clarifications toContract Terms and Condition」（以下稱闡明條款）亦均由民航局提出，並由民航局長Teh-Ming Liu於系爭闡明條款末頁簽名（見外放中信局購料處合約卷夾第63頁）。

契約附件第1.0條「Payment Terms」約定「Payment byCTC/CAA to LAIL」、第1.3條約定「L/C……shallissued by CTC/CAA」（見同上合約卷夾第3頁），另附件「List of ROC Furnished Equipment and Services」（中華民國政府應提供之設備及服務，簡稱GFE)亦係由民航局負責執行(見外放中信局購料處合約卷夾第31頁)，闡明條款第4.1條並約定民航局可請求額外的設備、 服務或兩者，第5.1條ａ項約定民航局可終止契約，第5.4條約定民航局有權要求暫時停止工作，第20條約定民航局有權指派2人組成計劃協調小組 ，用以監控整體計劃之技術及時程進度（見同上合約卷夾第44、45、51頁），足見民航局就系爭航管契約之簽訂及執行，應係居於主導地位。

４、而按當事人間契約之成立，係以雙方當事人意思合致為要件，至其是否到場或簽章，均與契約成立之要件無關（民法第153條第1項規定及最高法院 18年上字第157號判例參照）。參酌契約附件之闡明條款係由民航局提出，並由民航局長Teh-Ming Liu於系爭闡明條款末頁簽名（見外放中信局購料處合約卷夾第63頁）。契約附件第1.0條「Pay-ment Terms」約定「Payment by CTC/CAA to LAIL」，約定付款義務人包括中信局及民航局、第1.3條約定信用狀由中信局或民航局簽發「L/C……shall issued by CTC/CAA」（見同上合約卷夾第3頁），另契約附件「List of

ROC Furnished Equipment and Services」（簡稱GFE)亦係由民航局負責執行(見同上合約卷夾第31頁)，另系爭闡明條款第4.1條約定「It is recognized that addi-tional equipment, services or both, other thanthose listed in the CAA/CTC RFP may be required

and requested by the CAA（雙方認知除了民航局／中信局之招標規定所臚列者外，民航局可能需要及要求額外之設備、服務或以上兩者）」、第5.1條第a項約定民航局有「termination」系爭航管契約之權利、第5.1條第b項約定美商洛克希德公司因民航局之違約而有終止系爭航管契約之權利、第5.4條約定民航局有權要求暫時停止工作，第20條約定民航局有權指派2人組成計劃協調小組，用以監控整體計劃之技術及時程進度（見同上合約卷夾第44、

45、51、61頁），既分別將民航局就系爭航管契約所得行使及負擔之權利義務予以明定，可見民航局自身亦得依據系爭航管契約行使權利、履行義務，應認民航局亦已與被上訴人公司間達成意思合致，而具有締約當事人之身分。

（二）洛克希德電子公司是否為本件契約之當事人？

１、查洛克希德電子公司（簡稱LEC）為系爭契約之得標人（Bidder）及製造商（Manufacturer），載明於契約FORM B（見中信局購料處合約卷夾第1頁） ，是洛克希德電子公司係為與中信局就系爭契約意思表示合致者，自為系爭契約之當事人，應無疑義。

２、被上訴人雖以契約FORM B投標欄第8行記載「LockheedAircrarft Int'l Ltd.,to act as Contractor」，主張洛克希德電子公司非契約之當事人云云，惟查闡明條款第22條約定「As a condition of contract, LEC reserves

the right to operate through any Lockheed domestic

or foreign subsidiary and /or associated companies

in the performance of any resultant contract.In arecognition of this right, and to be agree to by

the parties at the date of contract.Lockheed Aircraft International Limited(LAIL) a subsidiary of

the Lockheed Corporation shall be the Lockheedcontract party. Lockheed Aircraft InternationalLimited's acceptance of contract obligations isindicated by its signature below. （在合約條款之下，洛克希德電子公司保留經由洛克希德公司國內、外之子公司或關係公司履行任何相關合約的權利。在合約簽訂當日之當事人之同意與認知下，洛克希德公司之子公司洛克希德飛機公司將為洛克希德一方之契約當事人。洛克希德飛機公司經由下面的簽名而接受本合約之義務）」，並由洛克希德電子公司副總裁兼總經理 RobertJ.Melnick共同簽署上開闡明條款（見中信局購料處合約卷夾第62、63頁），足見洛克希德電子公司雖同意由洛克希德飛機公司出面與簽訂書面契約，惟其仍保有履行系爭契約之權利，與洛克希德飛機公司同系爭契約之當事人。

３、至於契約之修訂由洛克希德飛機公司出面簽署，一如契約相對人亦單獨由中信局簽署，核係僅此二人為書面契約之簽署人之當然結果，並不影響其為契約當事人事實。況闡明條款第1條約定洛克希德電子公司負責安排運送各項設備、零組件至裝設地點並負擔費用， 第4.2條約定洛克希德電子公司無法依約執行其工作，而可宥恕之情形，第5.

3.2條約定洛克希德電子公司可終止契約……， 其各條所約定供應方之權利及義務，均以洛克希德電子公司稱之，被上訴人主張洛克希德電子公司非系爭契約之當事人，並無足取。

二、就系爭契約之履行、遲延罰款及損害賠償，洛克希德馬汀公司應否與洛克希德飛機公司負連帶責任？

（一）查被上訴人洛克希德飛機公司之母公司即美商洛克希德公司於73年1月4日出具保證函同意擔任洛克希德飛機公司就系爭契約之保證人，載明「２.IN CONSIDERATION OF CTC/

CAA ENTERING INTO THE CONTRACT, LC HEREBY UNCONDI-TIONALY AND IRREVOCABLY AND AS OBLIGATION OF LC：

A.UNDERTAKES TO CTC/CAA TO PROCURE THE FULL ANDCOMPLETE OBSERVANCE AND PEROFRMANCE BY LAIL OFEACH AND EVERY PROVISION CONTAINED IN THE CONTRACT

ON LAIL'S PARTY TO BE OBSERVED OR PERFORMED,AND...

B. THE CTC/CAA SHALL BE ENTITLED TO PROCEED HERE-UNDER AGAINST LC WITHOUT GIVING ANY PRIOR NOTICE

TO OR ASSERTING ANY PRIOR CLAIM AGAINST LAIL....（基於中信局/民航局締結上開合約， 美商洛克希德公司對下列各款所列事項為無條件、不可撤回並視為洛克希德公司之義務之保證：A.確認洛克希德飛機公司會遵守並履行系爭航管契約所定洛克希德飛機公司應遵守並履行之契約義務…… ３、… B.中信局/民航局依本保證書有權對洛克希德公司起訴，而無須為事先之通知或先行對洛克希德飛機公司起訴請求……）」等語，有保證書在卷可稽（見中信局購料處合約卷夾第69頁），既約定美商洛克希德公司對於洛克希德飛機公司就系爭契約之義務之履行，負保證責任，則洛克希德飛機公司因系爭契約之履行所生之一切義務，均在美商洛克希德公司保證之範圍。而關於契約未能履行致契約終止、解除之價金之返還，及所生之損害、遲延罰款，均屬關於契約之履行所生之義務，自均在美商洛克希德保證之範圍內，美商洛克希德公司自應就爭契約負保證人責任，嗣因美商洛克希德公司與洛克希德馬汀公司合併消滅，而以洛克希德馬汀公司為存續公司，則上訴人主張洛克希德馬汀公司應就系爭契約之履行、遲延罰款及損害賠償負保證人責任，應為可取。

（二）被上訴人雖抗辯美商洛克希德公司保證之範圍僅在於保證洛克希德飛機公司履行建置系爭航管自動化系統之義務，不及於契約價金之返還、遲延罰款及損害賠償云云，惟系爭保證函既保證洛克希德飛機公司遵守並履行依系爭契約所定應遵守及履行之義務，則於洛克希德飛機公司因故不能遵守及履行系爭契約應遵守及履行之義務時，保證人就洛克希德飛機公司不能履行所致之責任及損害自負保證人責任，被上訴人抗辯美商洛克希德公司保證之範圍不及於契約價金之返還、遲延罰款及損害賠償云云，並無足取。

（三）又保證人於系爭保證函既明確表示上訴人無須事先通知或先行對洛克希德飛機公司起訴，保證人即無條件的對於洛克希德飛機公司就系爭契約之義務負責，足見保證人已放棄先訴抗辯權，準此，債權人於保證人應負保證責任之情事發生時，即可對於債務人、保證人之任一方或全體，同時或先後為全部或一部之請求，則上訴人主張保證人洛克希德馬汀公司所負者為連帶保證人責任，應就系爭契約價金之返還、遲延罰款及損害賠償，與洛克希德飛機公司負連帶責任，應為可取。

（四）被上訴人雖又抗辯連帶保證並非連帶債務，洛克希德馬汀公司就系爭契約價金之返還、遲延罰款及損害賠償，不與洛克希德飛機公司負連帶責任云云，惟按保證人依民法第745條規定，於債權人未就主債務人之財產強制執行而無效果前，對於債權人得拒絕清償，是為保證責任之補充性，保證人有檢索之抗辯權。惟於保證人拋棄先訴抗辯權時，因債權人無需先就主債務人之財產為強制執行無效果，即可逕向保證人請求清償，則保證人於此所負者，即非屬補充性之保證債務責任。而「保證債務之所謂連帶，係指保證人與主債務人負同一債務，對於債權人各負全部給付之責任者而言」（最高法院45年台上字第1426號判例參照），上訴人於洛克希德馬汀公司應負保證之情事發生時，既可對洛克希德飛機公司、或對洛克希德馬汀公司，或對二者，同時或先後為請求，洛克希德飛機公司與洛克希德馬汀公司對於上訴人所負者，自屬連帶責任，被上訴人抗辯洛克希德馬汀公司不與洛克希德飛機公司負連帶責任云云，並無可取。

三、系爭契約之性質為何？

（一）按稱「製造物供給契約」（作成物供給契約或工作物供給契約或買賣承攬）者，乃當事人之一方專以或主要以自己之材料，製成物品供給他方，而由他方給付報酬之謂。此項契約之性質，究係買賣，抑屬承攬？自以依當事人之意思而為解釋，以資定之。如當事人之意思，重在工作之完成（勞務之給付），適用承攬之規定；側重於財產權之移轉者，適用買賣之規定（參看本院59年台上字第1590判例意旨）；兩者無所偏重或輕重不分時，則認為承攬與買賣之混合契約，關於工作之完成，適用承攬之規定，關於財產權之移轉，即適用買賣之規定（最高法院99年度台上字第170號判決參照）。

（二）本件上訴人民航局為建置自動化之航空管制系統委由上訴人中信局公開招標，經洛克希德電子公司得標，而由被上訴人洛克希德飛機公司與上訴人中信局簽訂系爭契約，依約洛克希德飛機公司應建置交付台北區管制中心自動化系統，及台北、台中、高雄三個終端管制中心之自動化系統。上訴人民航局於開標前即於 71年6月30日先行完成航管自動化系統規格書，函送歐美十一家著名相關廠商評估並提供技術意見，再於 72年1月31日根據歐美廠商的評估意見，完成系統基本規格書的修訂，並列為招標文件，由上訴人中信局邀請歐美十家廠商參加兩段式比價投標。在72年6月10日投標期間屆滿前，上訴人民航局並於72年4月16日、72年5月14日、72年6月16日三次，統一答覆各廠商所提出的各項問題。 復為求慎重，並於72年9月17日至72年11月9日與洛克希德飛機公司及洛克希德電子公司先後舉行29次闡明會議，其中27次為有關技術方面的會議等情，已據上訴人陳明在卷（見原審卷六第38至39頁），參諸上開航空自動化系統係建置於上訴人民航局指定之處所，系爭契約當事人之意思，應係重在系爭航空自動化系統之建置完成，其性質應屬承攬。

（三）上訴人雖以系爭契約標單上已明白記載系爭契約係以「Whole lot; turn-key」，即整廠設備輸出為基礎，而國際貿易慣例，turn-key契約係被定性為買賣契約之一種，故系爭契約性質上係屬買賣契約云云。惟契約之性質究為買賣或承攬，應以當事人之意思係重在工作之完成或財產之移轉而定，非以國際貿易慣例之認定為準。系爭契約之闡明條款第19條第2項規定民航局人員可參與最後重要設計審核階段前，及設計審核階段過程中之系統設計活動；第20條第2項規定民航局設置協調聯絡小組監控整體計劃之技術與時程進度；第4.1條、第5.4條、第5.2條規定民航局可變更工作服務內容、停止工程之執行、終止契約（見中信局購料處合約卷夾第44至63頁），足見系爭契約非只要求組成系爭航管自動化系統之各項設備、器具、軟體產權之移轉，而係特別著重於工程進度及設計之檢討、審核，所有工程進度及設計之檢討均由民航局監督審核，以完成系爭航管自動化系統之建置，揆諸前開說明，其性質應屬承攬，上訴人以契約標單上Whole lot; turn-key」之記載，主張系爭契約之性質為買賣契約，應非可取。

四、成大航太系所及中科院之鑑定報告於本件有無證據能力？

（一）按法院認為必要時，得囑託機關、團體或商請外國機關、團體為鑑定或審查鑑定意見，其須說明者，由該機關或團體所指定之人為之，民事訴訟法第340條第1項定有明文。

查就系爭契約兩造間之爭議，當事人分別提起兩件訴訟，除本件上訴人訴請被上訴人返還價金等外，訴外人台灣洛克希德公司主張其受讓美商洛克希德公司及洛克希德飛機公司對於上訴人之損害賠償債權，訴請上訴人給付（原法院80年度重訴字第506號、本院90年度重上字第54號 ，以下稱另案)，另案第一、二審法院先後於85年10月3日、91年6月7日及 93年4月28日囑託成大航太所就兩造之違約責任及履約價額等事項進行鑑定，該所乃依序於 88年8月18日、93年2月1日及97年7月30日完成之鑑定報告 、補充鑑定報告及賠償鑑定報告，為兩造所不爭，並有上開三份鑑定報告在卷可稽（見外放證物）。上開三份既為法院囑託鑑定，自非無證據能力。

（二）上訴人雖主張系爭航管系統之規模及複雜性非一人可勝任鑑定工作，為兼顧鑑定結果之公正性及客觀性，不宜由個人擔任，另案原係選任成大航太所為鑑定機關，惟事實上系由被上訴人聲請之林清一教授個人進行，上開鑑定報告既非另案法院選任之鑑定機關所為，應無證據能力云云。查成大航太系所之鑑定報告固載明「委託成功大學航太系林清一教授鑑定」（見鑑定報告第2頁)，惟上開三份鑑定報告並非由該教授林清一個人所具名提出，且機關所為鑑定，本須藉由其所指定之人進行 ，此觀民事訴訟法第340條第1項後段規定即明， 是尚難僅以上開三份鑑定報告係由該教授林清一所主筆，即否認其形式上之證據能力。

（三）另中科院之鑑定報告，係本院就兩造四大項24小項之爭議事項是否屬於約外需求，及兩造之過失比例送請鑑定所得之鑑定報告，自具有證據能力。被上訴人雖以本院所選任之鑑定機關為中山科學院資訊通信研究所，惟系爭鑑定報告係由中山科學院智財經營管理辦公室所為，抗辯系爭鑑定報告無證據能力云云。查本院原固係委請中山科學院資訊通信研究所進行鑑定，惟中山科學院於收受本院囑託，經評估確認本件所鑑定需專業能量後，函覆本院將成立專案編組承接進行本件鑑定工作，並請本院提供鑑定項目四大項24小項相關資料，以利展開鑑定工作，有該院 95年8月29日曄治字第0950009535號函在卷可稽（見本院卷四第23頁），本院鑑於中山科學院之專業技術領域包括交通運輸、控制工程、電機、電子、通訊工程、航太工程等，並配合「智財經營管理辦公室」專利侵權鑑定團隊執行專利侵權鑑定（見本院卷三第79頁），乃同意由中山科學院成立之專案編組進行鑑定，並請當事人提出相關資料檢送鑑定機關，兩造亦配合提出相關資料送交鑑定機關（見本院卷四第28、33頁），嗣並陸續多次提出大量之資料及陳述意見之文件送交鑑定機關（見外放鑑定機關返還資料三箱），是本件本院囑託鑑定之機關已由中山科學院資訊通信研究所，改為中山科學院成立之專案編組。嗣中山科學院於96年6月5日通知提供補充資料，俾利執行鑑定工作之同時，通知於鑑定執行期間，有關函文送文單位更正為「國防部軍備局中山科學研究院智財經營管理辦公室」（見本院卷四第48頁），參諸中山科學院曾於96年5月1日表示對於鑑定工作，已積極進行中，成立專案編組，由各種專業領域之成員、專家參與討論、研判，每一個月會開會一次，彙整討論初步結果（見本院卷四第43頁），足見中山科學院僅係將其為本件鑑定所成立之專案編組，設於智財經營管理辦公室，以該辦公室為鑑定工作進行處所及統合單位，實際進行鑑定工作者，仍為其所成立之專案編組。經函詢鑑定報告記載該院智財經營管理辦公室為執行單位之緣由，亦據中山科學院覆函稱：「為執行本鑑定案，本院納編航管經驗、戰管經驗、專案管理、系統工程、法律專業與購案履約專業人員組成鑑定專案小組，由於工作涵括本院多個單位，乃以本院『智財經營管理辦公室』為鑑定案統合單位執行本鑑定案，……其中執行本鑑定案之單位包含本院『資訊通訊研究所』」等語（見本院卷九第41頁），該鑑定報告既係本院囑託之鑑定機關所為，自非無證據能力。被上訴人主張鑑定報告作成單位與囑託鑑定單位不同，系爭鑑定報告沒有證據能力，容有誤會。

（四）又按證據能力與證據力有別，前者係指於人或物中有為證據方法之資格，後者則係證據方法就應證事實所能證明之價值。民事訴訟法第355條第1項之規定，僅具有形式上證據力，至其實質上證據力之有無，則由事實審法院依自由心證判斷之。上開四份鑑定報告雖均有證據能力，至於其實質上之證據力如何，則應由本院本諸調查證據之結果，依自由心證而為判斷，自不待言。

五、上訴人有無要求被上訴人提供約外之設備、服務或功能需求？洛克希德公司未能於期限內交付「航管自動化系統」，有無闡明條款第4.2條所定之可宥恕情形？查兩造契約闡明條款（Clarifications to Contract Terms

and Conditions）第4.1條規定「Change to Equipment and/or Services：It is recognized that additional e-quipment, services or both,other than those listed

in the CAA/CTC RFP may be required and requested by

the CAA.In the event that the scope of LEC's obliga-tions under this Contract is increased because ofsuch requests by the CAA. LEC shall be entitled to

an equitable adjustment in price and/or schedule for

any item affected by such change.（變更及/或服務之變更： 雙方認知除了民航局/中信局工程招標文件所列者之外，民航局可能需要及要求額外的設備、服務、或以上兩者。

如因民航局該等額外，要求致使本契約下之美商洛克希德電子公司義務增加，美商洛克希德電子公司有權對受變更影響之項目之價格及/或時程，做衡平合理的調整。」、第4.2條規定「Excusable Delays：In the event that LEC isprevented from performing its dutties under thisContract as result of any or all of the following:

1.Unavailability of building and/or facilities forsystem installation. 2.Unavailability of GovernmentFurnished Equipment (GFE); 3.Untimely data item ap-provals;4.Untimely completion of any other CAA obli-gations under the Contract. 5.Force majeure; and or

6. Any delay(s) due to causes or events beyond thereasonable control of CAA, LEC and/or its nominatedmajor Subcontractor(s); then,a day per day extensionshall be applied to the concernned system completionschedule under the Contract.Additionally, CAA willrequest a corresponding program schedule change.Allmatters related to such change(s) shall be negoti-ated to the mutual satisfaction of both parties.（可宥恕之遲延：如因下列任何原因，致使美商洛克希德電子公司無法依本契約執行其工作時:1.供系統安裝之建築及/或設施未備供使用者;2.政府提供之設備(GFE)未備供使用者；3.未及時認可或核准資料項目者；4.民航局未能依約及時完成於本契約下之任何其他義務；5.不可抗力；及或6.任何超出民航局、美商洛克希德電子公司及／或其等所指定之要次承包商合理控制範圍外之事件所致之任何遲延；即應將本契約中受影響之系統完工時程逐日順延。除此之外，民航局將要求一份對應之修訂計劃時程。所有與此等變更有關事項，應由雙方議定至互滿意為止）」（見中信局購料處合約卷夾第44頁）。又系爭航管工程招標前，民航局即已擬就該工程所要求之基本需求規章，作為招標文件(RFP）之一，嗣洛克希德電子公司得標後，民航局復於72年9月17日至同年11月9日間，與洛克希德電子公司、洛克希德飛機公司舉行27次澄清會議，就系爭航管工程之需求規章逐條討論，並作成共計104項之澄清會議記錄（A CAA Summary of Clarifications

to the REP documents），雙方始於72年12月20日簽約，並於「ATTACHMENT TO FORM B CONTRACT DOCUMENT」將上開招標文件、招標文件敘及之文件、基本需求規章、澄清會議記錄、洛克希德電子公司之投標文件等均列為系爭航管契約之文件，並規定各契約文件之效力優先順序，有該契約FORM B、「ATTACHMENT TO FORM B CONTRACT DOCUMENT」、澄清會議記錄等在卷可稽（見外放合約文件㈠至㈢）。是兩造契約約定洛克希德公司應提供之服務項目及其內容如何、上訴人有無為約外之要求、 被上訴人有無闡明條款第4.2條所定可宥恕之情形，即應視各契約文件相關之約定內容而定。被上訴人雖主張民航局提出之基本需求規章，即台北地區管制中心自動化系統規格書（TACC）、終端管制中心自動化系統規格書（TCC）及雷達資料抽讀器規格書（RDE），為系爭工程實質技術內容及工程項目之唯一規範云云，惟兩造既就系爭航管工程之需求規章逐條討論作成共計104項之澄清會議記錄，且與工作說明書等其他招標文件，同列為契約文件之一，則某項工作是否屬於契約約定之範圍內，自應綜觀契約各項文件為綜合判斷，被上訴人主張僅以TACC、TCC及RDE規格書之內容決之，容有誤會。茲就被上訴人主張之各項事由，依中科院鑑定報告所列順序，及成大航太所鑑定報告未包含於中科院鑑定報告部分依成大航太所鑑定報告所列順序，分別審究其是否為約外要求、 及被上訴人有無闡明條款第4.2條第1項各款所定可宥恕情形，說明如下：

（）關於被上訴人主張「航路之約外需求」，即民航局要求之偏好航路（Preferential Route），是否為航路之約外要求部分（中科院鑑定報告第一大項第1小項）？

１、被上訴人主張基本需求規格書即TACC、TCC及RDE之規格書，為系爭航管工程實質技術內容及工程項目之唯一規範，TACC規格書關於飛航資料之處理規定於第3.7.3.2.11.2節、第3.7.3.2.11.3節及第3.7.3.2.13.1節，而TACC規格書第3.7.3.2.11.2節、第3.7.3.2.11.3節規定TACC系統應使用「標準儀器起飛（SID)」、「標準終端降落航路（STAR）」處理之；第3.7.3.2.13.1節規定計算正常固定時間之輸入資料應包括SID及STAR，TACC僅規定、 要求對於標準航路（SID及STAR航路)之飛航資料處理，未要求偏好航路之飛航資料處理，主張民航局要求之偏好航路為約外要求，惟為上訴人所否認。

２、查某項工作是否屬於契約約定之範圍內，自應綜觀契約各項文件為綜合判斷，非僅以TACC、TCC及RDE規格書之內容決之，已如前述。且TACC規格書第3.7.2.1.46節「SelectAdapted Route Option」規定：「The capability shall

be provided to select an adapted route/runway op-tion inresponse to commonly experienced operation-

al changes. Input data shall consist of a routepoit and an indicator identifying which alterna-tive is to be implemented. Processing shall in-clude storing the selected data, reprocessingflight plan routes containing the changed data,

and output at all affected CSUs, AMIS and TCC」，已規定被上訴人承作之航管自動化系統可提供選擇調整航路之能力，輸入資料包括航路點及識別替代指示器，其訊號處理包括選擇數之儲存，飛航計劃資料發據轉換功能，以及輸出至受影響的CSU、AMIS、TCC等（見外放TA CC 基本規格書第3-197頁）。 而系爭航管自動化系統之設計，洛克希德公司於71年10月針對民航局公開閱覽所提供之意見書第2.3. 2.1節B「Flight Plan Message Processing」即已提及:「In addition, this function determines

the eligibility of the route for preferentialroute application or adapted direct routes 」 （見本院卷六第37頁）， 於其投標文件第2冊 Engineering第3-19頁亦載 「In addition, the eliqibility of theroute for preferential route application or adap-

ted direct routes is determined」 ，於同冊第3-19頁並表示其次承包商OAO公司將援用美國NAS演算法為TACC軟體設計之標準，有能力提供民航局與美國NAS系統相同之功能：「The U.S National Airspace System（NASH）with which OAO is intimately familiar,performsessentially all FDP functions required for theTACC in a field- proven system.The NAS softwareprovides algorithms and safety features applicable

to the TACC system. OAO plans to take these NASalgorithms and features and carry them over into asystem specifically designed For the Stratusdistributed network using TACC Software designstandards.」， 而美國NAS系統在民國73年之前即已具備偏好航路之功能，被上訴人於 73年8月6日PDR會議中，關於TACC之PDR待決工作項目第41項， 於上訴人詢問PARs與PDRs是否為飛航計劃處理系統所應要求之功能時，被上訴人亦回答是（見本院卷十四第52頁），上訴人主張偏好航路自始即由被上訴人承諾納入系爭航管自動化系統應有之功能，非約外要求尚非無據。

３、且本件契約之工作說明書（Statement of Work，簡稱SOW） 於第5.3節中明確規定本件航管自動化系統工程軟硬體之發展管理均依據MIL-STD-1521A標準執行初步設計審核與細部設計審核，即依據系統規格，再經由初步設計、細部設計過程，將民航局之需求轉化為最終之軟體系統，採購建置所需之航管自動化系統(見本院卷九第175-176頁，外放Statement of Work第5-7頁）。CAA Summary ofclarifications to the RFP Documents （民航局對招標文件之闡明摘要，以下稱闡明摘要）亦規定TACC規格書應以MIL-STD-490為程式發展之軟體文件製作標準(見本院卷九第177-179頁)。則民航局於需求轉換為設計藍圖之過程中，就功能性之需求提出說明或澄清，並對被上訴人之設計為審核及指正，應均不屬於約外需求。況系爭航管自動化系統涉及飛航管制及自動化，攸關生命、身體及財產之安全，自有必要採取嚴格之標準化規範，而軍事規範已充分考量嚴苛之實戰環境與狀況，在可靠性、可維修性、安全性與在惡劣環境下運作能力等方面之要求均高於一般商用規範，為確保系爭航管自動化系統之安全性、穩定度與耐受度不可或缺之重要標準。

４、本件經送中科院鑑定結果，亦認「依據本工程案基本需求規章，SOW第5.3節明確律訂本工程案系統軟硬體發展管理係依據MIL-STD-1521A 規範執行初期設計審核(PDR) 、最後重要設計審核(CDR)。 依據SOW第5.6.2節所述，工程需求規格須符合MIL-STD- 490規範，即基本需求規章係說明系統之基本功能需求，至於詳細系統需求，則須在後續的

PDR、CDR中，經雙方研討後確定。依一般狀況，偏好降落航路（PARs，Preferential Arrival Router)，偏好起飛航路（PDRs，Preferential Departure Router)，偏好起飛降落航路 PDARs（Preferential Departure ArrivalRouter）之功能應在初步設計申提出，而應雙方澄清實際需求內容後，再於細部設計中說明。依據附件三十一號顯示，民國73年8月6日所舉行的PDR會議，於TACC（TaipeiArea Control Center) PDR之待決工作項目第41項，民航局詢問洛克希德公司PARs、PDRs等需求是否為必需之項目（in FPP (Flight Plan Processing) Function，洛克希德公司答覆為「是」(「Answer,"YES"」)，可見有關PARs, PDRs等需求並非屬於約外要求。」（見外放鑑定報告第4頁） 。被上訴人抗辯民航局要求之偏好航路為約外要求，應非可取。

５、被上訴人雖抗辯MIL-STD-1521A及MIL-490僅為程序性之一般規範，非可用於界定系爭航管工程之具體工作範圍及內容，又SOW中僅5.6.2節結構管理項下有規定MIL-STD-490之適用，且其項下5.6.2.1.6電腦程式規格已由洛克希德電子公司之投標須知之Computer Program ConfigurationItem Development Specification所取代，已排除MIL-STD-490之適用云云。 惟民航局之闡明摘要及工作說明書S0W分別為效力優先順序第4及第5之契約文件， 前者應優先於後者適用，而前者已規定TACC規格書應以MIL-STD-490全部章節為程式發展之軟體文件製作標準(見本院卷九第177至179頁)。且查SOW第5.3.2及5.3.3節關於硬體設計及電腦程式設計之Preliminary Design Reviews（PDR 初期設計審核）及Critical Design Reviews（CDR細部設計審核）均規定適用MIL-STD-1521A。SOW第5.6.2節Configuration Manatement項下第5.6.2.1.2節規定「Thecontractor shall comply with the requirements ofAppendicesII and III, MIL -STD-490, in the prepa-ration of Types BI and B2 CI development specifi-cations for newly designed or modified off-the-shelf equipment.......Howevey,the CAA reserves theright to unilaterally designate any item as engi-neering critical when one or more of the critieria

of paragraph 3.1.3,2,2(a) of MIL- STD-490 are ap-plicable.」。雖然闡明摘要中之Contract Data Re-quirements List and Data item Descriptions（合約資料需求清冊）中關於項目010 Computer Program Confi-guration Item Development Specification之Data ItemDescription， 嗣經被上訴人投標文件3.7.1至3.7.7.7之內容所取代(見本院卷十三第89至104頁總說明附件11、12），惟其載明「This document could be combined withsimilar descriptions of facllitie's not developedunder this contract to Provide a description of

the complete ATC systemin the Republic of China」（見本院卷十三第100頁），並無言明排除MIL-STD-490之適用，且闡明摘要於其附表2-1，將引用MIL-STD-490之SOW第5.6.2.1.6節等規定明文列為系爭航管自動化系統之軟體文件製作標準（見本院卷十四第194至196頁）。被上訴人以MIL-STD-490之適用已被排除，質疑中科院之鑑定結果，為不可採。

６、被上訴人雖又抗辯民航局已於 74年5月21日函文承認偏好航路為約外需求，惟為上訴人所否認，查民航局 74年5月21日函文稱「Attached are copies of the final ver-sions of PDR Action Item 51(date 85-04-25)and 52(date 85-05-15).These have been updated to reflectagreements reach in our discission on "out-of-scope" items, No new features have been added,」（見本院卷十三第177頁），係針對PDR會議待辦事項第51與52項之「使用中跑道」 （Runway in use）所為表示，並未提及PDR會議待辦事項第41項「偏好航路」 ，被上訴人引民航局上開函文，主張民航局已承認偏好航路為約外要求，委無足取。

７、綜上，民航局要求之偏好航路（Preferential Route）既非約外要求，則被上訴人自不得依闡明條款4.1條約定主張調整其完工時程，且民航局於 73年11月9日洛克希德表示此部分為約外要求時，即於72年11月21日發函表示明確表示偏好航路乃屬必要，為屬約定要求等情，已據被上訴人陳明在卷（見本院卷十三第127頁)，並有民航局72年11月21日函文在卷足憑（見本院卷十三第161頁)，是亦難認就此部分有「民航局未能依約及時完成於本契約下之任何其他義務」，或「任何超出民航局、美商洛克希德電子公司及/或其等所指定之要次承包商合理控制範圍外之事件所致之任何遲延」之情形，被上訴人主張此部分有闡明條款第4.2條第1項第4、6款所定可宥恕之情形，亦無可取。

（）關於被上訴人主張「空軍航管中心界面連接之定義」部分（中科院鑑定報告第一大項第2小項）：

１、民航局於73年6月21日會議中要求使用128位元之訊息格式及要求CCIITT X.25介面規則應與空軍空管中心系統相容，是否為約外要求？及要求修改一位元（1 byte）之閒置字元（idle character）為二位元（2 bits），是否與依據LAP-B規格完成之韌體不相容而必須對該韌體為重大修改，而屬約外要求?㈠查契約文件「Preliminary Taipei Area Control Center

Automation System/Air Defense Center InterfaceControl Document（航路與防空自動化系統之銜接控制文件，以下稱空防介面控制文件）」第1.2節規定：「Thisdocument defines the characteristics of the hard-ware,software and operational elements that arenecessary for the timely and efffcient transfer ofdata between the TACC automatlon system and the

Air Defense System. The data transfer includes thetransmission of long range radar (LRR)data from

the Air Defense Center (ADC) to the TACC and theexchaye of operational data including the flightdata and the track data between the TACC and the

Air Defense Center.（本文件定義了台北區管中心(TACC)與空軍戰管中心(ADC，Air Defense Center）間即時、充分的資料傳遞所必須之軟硬體特性及操作諸元。資料傳輸包含自ADC傳輸長程雷達資料至TACC， 及含飛行資料與航跡資料在內之操作資料交換」，第1.3節規定：「Thefunctional capability and the design of the TACCAutomation System---Air Defense System interface

are constrained by decisions which are made tomeet the basic objectives of the interface. Theseconstraints are:1. Interfaces will be designedsuch that the cost impact on devices that mustmeet the inter- face requirements is kept to aminimum.2.Existing standards shall be used when-ever possible in establishing the interface re-quirements.3.Modular design shall be emphasized onboth sides of the interface with minimum impact to

the overall system.（TACC與ADC間介面之功能，應受介面之基本目標所限制：1.介面之設計，應在符合介面要求的前提下，將成本上之衝擊降至最低。2.既存之標準應在建置介面要求時，盡量援用。3.設計之調整，應注重雙方之介面及對系統最低之衝擊 （見空防介面控制文件第1-1、1-2頁、本院卷九第171至173頁）。 依此，系爭航管系統應與業已存在之空軍戰管中（ADC）相容。 而空防介面控制文件所定之通訊協定，原係CCITT V.10、CCITT V.24及CCITT V.26等標準 （見外放空防介面控制文件第2-3頁、本院卷十四第179至181頁），被上訴人如欲採用前開標準以外之CCITT X.25標準， 自需使該標準能與ADC系統相容。則上訴人主張空軍戰管中心於系爭航管自動化系統招標時，已為運作中之系統，為避免彼此計算欠缺一致性而影響飛航管理之正確性與時效性，本件契約招標文件乃要求系爭航管自動化系統在涉及空軍戰管中心介面時，應能與空軍戰管中心系統相容，且能及時交換傳輸彼此之資料，應為可取。

㈡又系爭契約空防介面控制文件第2.3節原約定通信介面應

採用CCITT V.10、CCITT V.24及CCITT V.26之規則，雖締約雙方已於1984年2月9日協議改採CCITT X.25之標準（見本院卷七第147頁），惟空防介面控制文件第5.1.1節「

3. Each message shall consist of 128 bits includ-

ing 98 information bits and 7 paritybits.」已約定長程雷達資料之介面功能特性應採用128位元之訊息格式，則民航局要求CCITT X.25介面規則應與空軍戰管中心系統相容及使用128位元之訊息格式， 均屬建立TACC系統介面功能之需求事項，應未超出契約約定需求之範圍。

㈢此部分經送中科院鑑定結果，亦認「基本需求規章中提及

，有涉及軍方之介面時，均規定盡可能使用當時已使用之標準，故民航局於1984年6月28日會議記錄中所要求CCITT

X.25介面規則應與空軍戰管中心系統相容及使用128 位元之訊息格式，並未超出台北區管中心基本需求規章介面控制文件之範圍（見外放鑑定報告第7頁）。上訴人主張此部分非屬約外需求，應為可取。

㈣此部分既非約外要求，則被上訴人自不得依闡明條款4.1

條約定主張調整其完工時程。且民航局於 73年6月21日會議中即要求使用128位元之訊息格式及要求 CCITT X.25介面規則應與空軍空管中心系統相容兩造嗣已於 73年6月27日、74年3月12日、74年8月8日、75年8月30日、 76年9月10日為完工期限之變更，被上訴人如因上訴人此項需求而有增加工期之必要，衡情亦已於隨後之變更完工期限中為調整。被上訴人主張其可依闡明條款第4.2條第1項各款約定展延完工期限，應非可取。

２、民航局要求修改一位元（1 byte）之閒置字元（idlecharacter）為二位元（2 bits），是否為約外要求？㈠被上訴人主張依雙方73年2月9日待辦事項會議紀錄，雙方

同意系爭航管系統電腦系統之內部及外部通訊，應符含國際電報電話諮詢委員會（CCITT）X.25中聯結存取程序B版即（CCITT X.25 LAP-B）之高階資料聯結控制規則。嗣我國空軍提出於73年6月28日會議表示CCITT X.25 LAP- B介面規則與ADC系統不相容，要求應供適用非標準化之交換資訊規則，民航局復於74年9月26日函文要求將符合CCITT

X.25 LAP-B規格之一位元組（1 byte）閒置字元（idlecharacter)，更改為二位元，顯係變更雙方73年2月9日達成之協議，自屬約外要求。嗣經反覆冗長討論，且民航局以不予核准介面控制文件相脅，洛克希德被迫於 75年5月21日提出之 75年4月10日介面控制文件修訂版，變更閒置字元為二位元，致洛克希德必須重新修改前已依雙方合意所設計以一位元組為基礎之韌體，延宕介面控制之設計及開發、進而影響系統介面之測試及整合，其得依闡明條款第4.1條、第4.2條展延完工期限云云，惟為上訴人所否認。

㈡查依契約空防介面控制文件第1.2節、1.3節規定，系爭航

管系統應與業已存在之空軍戰管中心（ADC） 相容，而介面控制文件所定之通訊協定，原係CCITT V.10、CCITT

V.24 與CCITT V.26等標準 （見外放空防介面控制文件第2-3頁、本院卷十四第179至181頁） ，被上訴人如欲採用前開標準以外之CCITT X.25標準， 自需使該標準能與ADC系統相容。 空防介面控制文件第5.1.1節已約定長程雷達資料之介面功能特性應採用128位元之訊息格式， 民航局要求CCITT X.25介面規則應與空軍戰管中心系統相容及使用128位元之訊息格式， 均屬建立TACC系統介面功能之需求事項，應未超出契約約定需求之範圍，已如前述。而閒置字元之設計為屬系爭航管介面設計之細部功能，依MIL-STD-1521A範之軟體設計，為依據系統規格， 再經由初步設計、細部設計過程，將民航局之需求轉化為最終之軟體系統，則民航局要求將一位元之閒置字元修改為二位元，應非約外要求。

㈢本件經送中科院鑑定結果，亦認 「依MIL-STD-1521A軟體

設計審查與稽核的規範，本工程案航管系統為之建置須經系統發展程序，民航局於本項所要求係屬細部功能，細部功能求在細部設計中，須經雙方研討後確定。因此民航局在細部設計之前捉出需求，係為合理」等語（見外放鑑定報告第11頁）。上訴人主張此部分非屬約外需求，應為可取。

㈣此部分既非約外要求，則被上訴人自不得依闡明條款4.1

條約定主張調整其完工時程。此部分既非約外要求，自亦無所謂「超出民航局、美商洛克希德電子公司及/或其等所指定之要次承包商合理控制範圍外之事件所致之遲延」可言，且民航局於 74年9月26日要求更改閒置字元為二位元，洛克希德嗣於 75年5月21日提出介面控制文件修訂版，變更閒置字元為二位元，而嗣締約雙方已於 75年8月30日、 76年9月10日為完工期限之變更，被上訴人如有因此項修訂而有增加工期之必要，衡情亦已於隨後之變更完工期限中為調整。被上訴人主張其得依闡明條款第4.2條第1項第4、6款順延系爭航管自動化系統之完工期限，亦無可取。

３、民航局74年9月26日所要求之台北區管中心與空軍空管中心應包括之介面功能，即「長程資訊終端之區分方位計畫」是否為約外要求？㈠被上訴人主張基本需求規章並未規定或要求長程資訊終端

機之系統設計中應包括區分方位計畫，我國空軍於 73年8月15日會議中始要求於長程資訊終端機之系統設計中加入區分方位計畫，當時洛克希德即表示不同意，雙方未達成協議，嗣民航局於75年8月5日函文中就介面控制文件修訂版所要求解決之事項中，亦未列入上開區分方位計畫，足見此為約外需求，被上訴人就此向上訴人為長期、反覆之澄清，影響介面控制之設計及開發，進而延宕系爭航管工程整體時程云云。

㈡查系爭契約空防介面控制文件中，固無提及長程資訊終端

之區分方位計畫，惟系爭航管自動化系統之建置係藉由系統分析掌握民航局之需求，並透過軟體之初步設計與細部設計將需求轉化為最終之軟體系統，則細部設計本難期於初步設計完成前，甚至簽約時，即已得全部確定，細部設定如未超逾系統原預定之功能，得否以其未於簽約當時提出，即謂係屬約外需求，尚非無疑。而本件經送中科院鑑定結果，即認「在SOW第5.3節明確律訂本工程案系統軟硬體發展管理係依據MIL-STD-1521A規範執行PDR、CDR。 依據SOW第5.6.2節所述， 工程需求規格須符合MIL-STD-490規範。民航局於本項所要求之介面功能屬細部功能，細部功能需求之作為在細部設計中須經雙方研討後確定，必須再進一步於PDR階段再加以定義方能明確，所以在基本需求規章對於細部功能需求有說明不足之情形係屬正常」、「依據上述鑑定說明，民航局 74年9月26日所要求之「長程資訊終端之區分方位計畫」並無超出台北區管中心基本需求規章之契約範圍」（見外放鑑定報告第8、9頁）。㈢況締約雙方固曾於73年8月15日會議中研商長程資訊終端

機之系統設計是否包括區分方位計畫，然並未達成協議，為被上訴人所陳明，並有該次會議記錄在卷可稽（見本院卷七第198頁），嗣民航局於75年3月21日函文中，雖曾再次要求洛克希德公司應將區分方位計畫列入長程資訊終端機之系統設計中(見本院卷十三第304頁），但洛克希德公司於 73年8月15日會議中已主張加入區分方位計畫之要求僅供參考而已，嗣民航局於75年8月5日函文就介面文件所要求解決之事項中，亦未包括上開要求(見本院卷七第199頁），顯見洛克希德公司從未執行民航局所為上開請求。則被上訴人主張其得依闡明條款第4.1條關於施作約外需求之規定調整完工時程，即無可取。被上訴人既未施作此工項，則其主張就此工項有闡明條款第4.2條第1項第4、6款所定「民航局未能依約及時完成於本契約下之任何其他義務」、「任何超出民航局、美商洛克希德電子公司及/或其等所指定之要次承包商合理控制範圍外之事件所致之任何遲延」之情形，其得順延系爭航管自動化系統之完工期限，亦無可取。

４、民航局 74年9月26日要求台北區管中心與空軍空管中心介面功能，即台北區管中心傳送至空軍空管中心之訊息應增加： ㈠在指出訊息（point-out）下回覆完整資料欄之要求，及㈡利益衝突之警訊，地形/障礙意外及領空保護（TOHAP）及緊急事件之訊息，是否為約外要求？㈠查契約文件空防介面控制文件第5.2.2.1.1節Point-out

Message約定：「2. The Full Data Block of a refer-enced track shall be capable of being sent with

the "poiot-out" message。3. A request for the FullData Block of a referenced track shall be capable

of being sent with the "point-out" message.（相關航跡之完整資料欄應能以「指出訊息」互相傳送。3.對相關航疏之完整資料要求，亦應能以「指出訊息」互相傳送）」，第5.2.2.2節規定「...Alert messages generated

by the TACC for air traffic hazards, terrain andobstacle hazards, airspace intrusion and emergencysituations will be seat to the ADC. （因飛航意外、地形及障礙意外、領空侵入及緊急情形等，由TACC系統發出之警示訊息，應能傳輸至ADC系統）」 （見外放空防介面控制文件第5-6、5-7頁)，再參酌其表5-4之記載（見同上文件第5-10頁），民航局所要求之上開指出訊息中對完整資料欄之回應，以及地形/障礙意外與領空保護(TOHAP)及緊急等訊息，均已涵括在上開約定之內。準此，上訴人主張其於74年9月26日就TACC與ADC間之資料傳輸，表示「在TACC傳送訊息至ADC時， 應能在指出訊息下回覆完整資料欄，且應包括衝突警訊（Conflict Alert)地形/障礙及領空保護功能（TOHAP, Terrain and obstacle hazard

and airspace protection）與緊急訊息(Emergency)」，僅在闡述介面控制文件第5.2.2.1.1節與第5.2.2.2節與第

1.2條等之內容， 以確保兩系統間之資料傳輸之及時性與充分性而已，並未提出任何約外需求，尚堪信取。

㈡被上訴人主雖張民航局於 73年6月28日會議時，以手寫修

改方式，刪去空防介面控制文件內表5-4中關於地形/障礙意外警訊部分之記載，惟民航局竟於其依變更後初期介面控制文件版本，於 74年1月10日提出介面控制文件之後八個月，突於 74年9月26日函文要求洛克希德新增上開訊息，為屬約外要求云云，惟為上訴人所否認。查被上訴人所提介面控制文件介面控制的修訂草稿，雖將表5-4中ter-rain and obstacle alerts and general infomation以筆手寫劃記刪除（見本院卷十三第341、342 頁），但未經雙方簽認，且上訴人所提之上開文件則未刪去此部分（見外放附件35），難認兩造已有刪除合意，則上訴人依此要求，應非屬約外要求。

㈢此部分經送中科院鑑定結果，亦認「以文件修定有效性而

言，修改部分，應經雙方於修改處簽證，洛克希德公司以手寫劃記刪除之資料，非通常修改程序，有效性仍待其他事實補充，…本工程案基本需求規章介面控制文件（附件有明確說明詳細的功能需求，故並無超出台北區管中心基本需求規章之契約範圍。民航局 74年9月26日所要求之台北區管中心與空軍戰管中心介面功能並無超出台北區管中心基本需求規章之契約範圍」（見鑑定報告第9至10頁）。另案成大航太所補充鑑定報告亦認「1.本項爭議辯方（指上訴人）所提資料對本項陳述，依據介面控制文件CAA-E-IC-001有具體的證明，洛克希德公司應依據合約完成之系統功能規格。2.本技術項目牽涉到航管系統啟用後之飛航安全，洛克希德公司自不應規避與推卸。3.本項爭議洛克希德公司應負全部份的責任」等語（見外放補充鑑定報告第11頁）。

㈣此部分既非約外要求，則被上訴人自不得依闡明條款4.1

條約定主張調整其完工時程。又此部分既非約外要求，自無所謂「超出民航局、美商洛克希德電子公司及／或其等所指定之要次承包商合理控制範圍外之事件所致之遲延」可言，且上訴人於74年9月26日就TACC與ADC間之資料傳輸，表示 「在TACC傳送訊息至ADC時，應能在指出訊息下回覆完整資料欄，且應包括衝突警訊地形／障礙及領空保護功能與緊急訊息」，僅在闡述空防介面控制文件第5.2.2.

1.1節與第5.2.2.2節與第1.2條等之內容， 已如前述，是自亦無所謂「民航局未能依約及時完成於本契約下之任何其他義務」 之情形，被上訴人主張其得依闡明條款第4.2條第1項第4、6款順延系爭航管自動化系統之完工期限，亦無可取。

５、民航局是否遲延審核介面控制文件？㈠被上訴人主張空防介面控制文件需經民航局核可後，洛克

希德始得據以執行，民航局於 72年1月提出初期介面控制文件，洛克希德據之於 74年1月10日提出修訂版予民航局審核，民航局遲至74年9月26日始回覆，且自74年1月至77年1月3年間，一再對個別細節予以重新定義、變更，更以不予核准相脅，要求洛克希德完成「長程資訊終端機之區分方位計畫」、「Point-out」 等約外要求，致文件一再修改，導致整體工程遲延；民航局未依GFE第15第1項、合約資料需求清冊（Contract Data Requirements List）第8規定， 於TACC或TCC之CDR階段完成審核並核准介面控制文件，審閱及核准文件遲延，應有闡明條款第4.2條第1項第2、3、4款可宥恕之事由云云，惟為上訴人所否認。

㈡按當事人就其主張之爭點，經依第1項第3款或前項為協議

者，應受其拘束。但經兩造同意變更，或因不可歸責於當事人之事由或依其他情形協議顯失公平者，不在此限。民事訴訟法第270條之1第3項定有明文。 又當事人意圖延滯訴訟或因重大過失，逾時始行提出攻擊或防禦方法者，法院得駁回之。當事人於第二審除有㈠因第一審法院違背法令致未能提出者、㈡事實發生於第一審法院言詞辯論終結後者、㈢對於在第一審已提出之攻擊或防禦方法為補充者、㈣事實於法院已顯著或為其職務上所已知或應依職權調查證據者㈤其他非可歸責於當事人之事由，致未能於第一審提出者、㈥如不許其提出顯失公平之情形外，不得提出新攻擊或防禦方法 ，民事訴訟法第196條第2項、第447條第1項亦有明文。 查關於「民航局是否遲延審核介面控制文件」，並不在中科院及成大航太所鑑定之範圍，被上訴人於中科院出具鑑定報告後，具狀表示其主張可歸責於上訴人之遲延事由共計四大項36小項，並列出其中上訴人未聲請鑑定之12項，亦註記「以下項目編號請參成大航太系所之鑑定報告」（見本院卷十第110頁） ，於本院整理兩造爭執事項時，提出之爭執事項表中，關於「系爭航管自動化系統是否因可歸責於民航局之事由而致遲延」之爭點，亦主張可歸責於民航局之事由有四大項36小項，並稱「洛克希德得依系爭航管契約第4.2條規定，就因可歸責於民航局事由所致之遲延，主張逐日展延系爭航管工程之工期。依國立成功大學航空太空系所民國93年2月1日補充鑑定報告，系爭航管工程應至少自動延展18個月」（見本院卷十一第4頁） ，足見被上訴人主張本件可歸責於民航局致遲延之事由，係以成大航太系所鑑定之項目為其範圍，並不包含「民航局是否遲延審核介面控制文件」之爭點。被上訴人並於 99年5月14日準備程序，與上訴人合意以當日本院兩造協商整理之爭點，為辯論之範圍（見本院卷十二第153頁）。 則被上訴人嗣於兩造依序就各爭點為說明及論述時，始主張「民航局遲延審核介面控制文件」，且查民航局審核介面控制文件有無遲延，事涉洛克希德提出之各項介面文件有無缺失？是否符合契約約定及系爭航管自動化控制系統之需求？是否完備可行？於正常情形下民航局所需之審核時期為何？等項，非僅憑兩造所提往來文件等所得判斷，而有送相關通訊、航太及控制等工程專業機構鑑定之必要。然本件訴訟自上訴人於78年間提訴迄今已逾20年，期間被上訴人並無不能提出之情形，然被上訴人於85年及91年另案送請成大航太所鑑定，及95年本院送請中科院鑑定時，均未爭執此部分，請求併送鑑定，於95年3月至98年8月中科院鑑定期間，亦未追加請求鑑定，則其於中科完成鑑定，兩造為爭點協議後，始於 99年7月29日具狀主張此一爭執事項，應認已逾時提出，如再送請鑑定單位鑑定，必有礙訴訟之終結，本院得不再送鑑定而為審酌。況民航局所提「長程資訊終端機之區分方位計畫」、「Point-out」等均非約外要求，已如前述，被上訴人主張民航局一再提出該等約外要求，致文件一再修改，而未能及時完成審閱及核准文件遲延，亦非有據。被上訴人主張民航局遲延審核介面控制文件，尚屬無法證明，其可依闡明條款第4.2條第2、3、4款規定展延完工期限，為無可取。

（）關於被上訴人主張「狀況顯示器列表之曖昧不明及擴張」部分（中科院鑑定報告第一大項第3小項）：

１、基本需求規章中關於狀況顯示器列表之需求規定，及降落、暫時控制、起飛、海岸暫止、地形／障礙意外及領空保護，飛航意外之列表格式及功能處理之說明，是否曖昧不明、模糊致承商無法或難以從事電腦程式之發展？民航局是否未依契約附件「中華民國政府供應設備清單（GFE）」前言、GFE第18條C項規定，如期提出狀況顯示器列表之格式及內容？㈠被上訴人主張、基本需求規章中關於狀況顯示器列表之需

求及降落、暫時控制、起飛等等規定，缺乏對於列表格式及功能處理之說明、或說明不足、模糊致其無法或難以從事電腦程式之發展，且依GFE前言規定，列於GFE下之項目，均應由民航局提出，以支援系爭航管工程之發展與完成，而TACC規格書就狀況顯示器列表之格式及內容之說明，未有規定或極為有限，依GFE第18條C項規定，民航局應於簽約後2個月內透過顯示器設計會議進行定義，並於3個月內提出，但民航局遲至73年3月6日至9日舉行第1次顯示器設計會議，且未提出任何列表格式及內容，於73年5月3日至5日第2次會議僅就起飛列表（Depart ture List）、降落列表（Inbound List）、海岸/暫止列表（Coast/Susp-

end List）提出有限、不完整的資訊，就地形／障礙意外及領空保護列表 （TOHAP List） 及飛航意外列表（ATHList） 則未提出任何資訊，違反其於GFE項下之義務云云，惟為上訴人所否認。

㈡查系爭航管自動化系統之建置係藉由系統分析掌握民航局

之需求，並透過軟體之初步設計與細部設計將需求轉化為最終之軟體系統，在初步設計及細部設計中，則依MIL-STD-1521A規範執行PDR、CDR， 以確定使用者之需求能確實反映並落實於軟體之具體設計，已如前述。故基本需求規章所定義的項目多為原則性的功能，並非詳列功能所需之詳細格式與處理方法，相關詳細格式與處理方法應於後續PDR、CDR階段工作中加以定義，是故基本需求規章如有抽象、說明不足或模糊之情形，應屬正常狀況。況本件契約於簽約前，締約雙方已先後舉行29次澄清會議，其中27次為有關技術方面的會議，會中雙方就基本規格說明，詳為討論，若有曖昧不明，被上訴人亦已有充分請求澄清及表示意見之機會。且洛克希德公司投標文件第二冊第2-50頁亦載明「The final version of this layout will berevuewed and finalized at the Preliminary DesignReview(PDR)（顯示器之最終格式應於PDR中定案）」（見外放投標文件第二冊，本院卷十四第63至64頁），顯示器之最終格式既於PDR中始定案， 則TACC規格書所載縱有抽象不明或模糊之情形， 因得於PDR中澄清定案，亦不致令洛克希德無法或難以從事電腦程式之發展。而此部分經中科院鑑定結果，亦表示「所謂基本需求規章，應屬MIL-STD- 490規範中所定義的Ａ規（System/segment speci-fication），基本需求規章所定義的項目大多屬於原則性的功能，並非詳列功能所需之詳細格式處理方法，依據本工程案PDR、CDR的審查流程與規範，相關詳細格式與處理方法應在後續工作中逐步確認，對於細部功能必須再進一步於PDR、CDR階段再加以定義方能明確，所以在需本需求規章有說明不足或模糊的情形係屬正常狀況。根據本院發展軟體經驗，通常Ａ規雖是由委託者訂定，但若內容有任何描述不明確的地方，受委託者基於自身所承擔之風險，應盡力與委託者澄清。『狀況顯示器列表』為本工程案重要功能需求，有關狀況顯示器格式定義，在合約文件中（GFE18）有說明簽約後兩個月(72年12月20日雙方簽約）由民航局、洛克希德公司及其次承包商舉行顯示器會議，律定顯示器格式後，由民航局交洛克希德公司執行設計。73年7月31日在PDR會議中，民航局與洛克希德公司決議由洛克希意公司R.Ames先生主導討論顯示器列表格式資料之內容。 另基本需本規章3.7.3.3.4.6.5.5.1~3節中，均已顯示各類列表每行資料有關入口符號之說明。洛克希德公司在本工程案簽約前曾舉行27次技術澄清會議，對不清楚的事項應在會議中澄清，因此對於系統需求說明仍有不足部分，不應歸咎於民航局。依據上述鑑定說明，基本需求規章中關於狀況顯示器列表之需求規定及降落、暫時控制、起飛、海岸暫止、地形／障礙意外及領空保護、飛行意外對於列表格式及功能處理之說明，為原則性之說明，至於詳細之需求，洛克希德公司應主動加以澄清或與民航局協調。若因基本需求規章對於細部需求說明不足，且洛克希德公司未主動加以澄清或與民航局協調，而致其無法或難以從事電腦程式發展之情形，不應完全歸咎於民航局」等語（見外放鑑定報告第14至15頁）。另案成大航太所補充鑑定報告亦認 「1.洛克希德曾於1983年3月間與民航局之技術性協調會議，所提出『規格模糊』之主張文件，並無書面佐證。……3.依據基本需求規章及合約，本飛航管制自動化系統必須符合國際民航組織所頒佈之規格標準、功能及格式來設計及建立。此外，民航局於邀書公告後依規定給予投標廠商充分的溝通機會，因此對顯示器之規格，洛克希德公司應於決標前獲得充分的溝通與詢問。4.顯示器列表規格明訂於國際民航組織相關附約（Annex）公告中，洛克希德公司應有充分的技術管道可以了解相關的問題。」（見外放補充鑑定報告第14至15頁）。

㈢又本件中華民國政府供應設備清單（GFE）前言記載「The

following is a listing of items that are to befurnished by CAA to supprot development and imple-mentation of the TACC and TCC Automation Systems」，其第18條C項規定：「Two months atter contractaward CAA, and LEC and its display Subcontractorwill convene a display conference and define dis-play formats to be delivered to LEC by CAA：...C.Situation Display：1.Tabular list placement ondisplay, where and are they mavable?2. List format

and.content? 3. List overflow by paging or scroll?

4. Are track vectors on the terminal displays de-sirable as the aircraft are maneuvering?」（見本院卷十三第410、411頁、原審被證卷第一冊第26、36頁）。

查系爭航管自動化契約於72年12月20日簽訂，而民航局（CAA）與洛克希德電子公司（LEC）及其次承包商於 73年3月6日至9日舉行第1次顯示器設計會議， 為被上訴人所陳明，並有該次會議記錄在卷可稽(見本院卷十三第413至415頁），雖略逾上開規定之2個月期限，惟會議之舉行需民航局、洛克希德電子公司及其次承商三方面協調，且顯示器設計會議係由三方研商澄清共同定義基本需求規章所載之需求，非單純由民航局單方面提出各項需求之細部規格明細，交洛克希德電子公司及其承商承作，自難期所有之問題均能一次會議中澄清並定義，以本件工程之龐大浩繁，尚難認第一次顯示器設計會議遲延十多天舉行，即致被上訴人工程延誤。 又上開GFE第18條並未規定民航局應於簽約後3個月內提出相關事項之最終需求， 且被上訴人主張民航局應於簽約後3個月內提出起飛列表、降落列表、海岸/暫止列表、地形/障礙意外及領空保護列表及飛航意外列表提出完整之需求說明，已有未合。況民航局於73年7月31日與洛克希德電子公司會議中，已決議由洛克希德公司之R.Ames先生負責安排狀況顯示器列表格式及功能之討論（見本院卷十三第456頁)，洛克希德公司就該不明確處，既負有安排會議用以釐清之責任，即不得藉詞TACC系統基本需求規章比該部分之規範不明確，遽指民航局未按時完成契約所應盡之義務。 況且系爭航管契約曾於74年8月8日第四次修正，延長完工期限， 而上開顯示器格式之疑義早在締約之初即已存在，果上開疑義確有致生工程延宕之虞，洛克希德公司當無不於延長工期事項中將之列入考量。

㈣而就民航局是否未依契約附件「中華民國政府供應設備清

單（GFE）」 前言、GFE第18條C項規定，如期提出狀況顯示器列表之格式及內容之爭議，中科院鑑定報告亦認「有關狀況顯示器格式定義，在合約文件中GFE18有說明……依據上述鑑定說明，依基本需求規章，民航局於73年5月3日至5日之第二次設計審核會議 ，民航局僅提出降落、暫時控制、起飛，海岸暫止等列表訊息內容，雖未對地形／障礙意外及領空保護(TOHAP)飛航意外(ATH)列表提出格式定義或訊息內容。但依附件七十號，洛克希德公司在投標書2-50頁中有說明 『本系統顯示功能在PDR時才做最後確認』 ，因此民航局於PDR會議提出此兩項需求，係屬合理，並無過失。 且73年7月31日在民航局與洛克希德公司的會議中，決議是由洛克希德公司R.Ames先生主導討論顯示器列表格式資料之內容」（見外放鑑定報告第15至16）。

被上訴人主張民航局未如期提出狀況顯示器列表之格式及內容，其有闡明條款第4.2條第2、4、6款之宥恕事由，應非可取。

２、民航局於系爭航管工程執行中，提出「起飛列表（Departture List）、降落列表（Inbound List）、海岸/暫止列表（Coast/Suspend List）等項附加入口符號（EntrySymbols），是否為約外要求？㈠被上訴人主張基本需求規章並未規定起飛列表（Depart

ture List）、降落列表（Inbound List）、海岸/暫止列表（Coast/Suspend List）等項應附加入口符號（EntrySymbols），民航局於73年10月18日函文提出上開列表附加入口符號，為屬約外要求。

㈡查TACC規格書（Taipei Area Control Center Automation

System Spceification）第3.7.3.3.4.6.5.5節規定「Thecapability shall be provided to display on the si-tuation display a departure traffic list, an in-bound traffic list, and a hold traffic list foreach CSU in which a particular list is applicable.These lists will be composed of specific flghtdata as provided by the RDP or the FDP function...」、第3.7.3.3.4.6.5.5.1節規定「...4. Each line of

a departure traffic list shall contain an airportidentifier, an aircraft identification preceded by

a symbol for position entry referencing purposes,

the assigned altitude in hundreds of feet, thedeparture time, and the assigned SSR code...」（見外放TACC規格書第3-328頁、第3-330頁），雖未有「入口符號（Entry Symbols）」 之記載，惟洛克希德公司投標文件第二冊第2-50頁已載明「The final version ofthis layout will be revuewed and finalized at thePreliminary Design Review(PDR)（顯示器之最終格式應於PDR中定案）」 （見外放投標文件第二冊，本院卷十四第63至64頁）。惟在執行PDR、CDR程序以確定並落實使用者需求之契約特性下，是否以得細部需求未於規格書中詳列，即屬約外需求，即非無疑。上訴人主張其於73年10月18日函表示關於起飛、降落及海岸／暫止等各類列表均應附加入口符號，不過重申TACC規格書第3.7.3.3.4.6.5.5.1以下之規定而已，並非提出約外需求，非無可取。就此中科院鑑定結果，亦認「基本需求規章係說明系統之基本功能需求，至於詳細的系統需求，則須在後續的PDR、CDR中經雙方研討後確定，且洛克希德在投標書2-50頁中有說明『本系統顯示功能在PDR時才做最後確認』 ，因此民航局所提事項均屬合理，其於73年10月18日就起飛列表、降落列表及海岸/暫止列表所提有關入口符號（Entry Sym-bols），並無超出台北區管中心基本需求規章之契約範圍」等語（見外放鑑定報告第17頁）。另案成大航太所補充鑑定報告亦認「起飛列表」為合約中的基本項目，至於列表內容與多寡，為合約執行之細節問題等語（見外放鑑定報告第17頁）。

㈢又民航局雖於73年10月18日函文中要求在起飛列表降落列

表、海岸／暫止列表等項應附加入口符號，惟嗣經洛克希德於73年11月9日提出立場說明書 ，表示TACC規格書僅規定、要求起飛列表、降落列表、海岸／暫止列表等項須有「定位入口符號(Position Entry Symbols)」，並未規定、要求該等列表應附加入口符號 （見本院卷十三第430頁） 後，民航局旋即於1984年12月8日通知洛克希德，表示同意洛克希德所為僅有「定位入口符號（Position EntrySymbols）」之設計（見本院卷十三第434頁）。民航局所為上開入口符號之要求，既經洛克希德公司拒絕，並經締約雙方迅速澄清，自難認系爭航管工程之遲延完工，與民航局所提上開要求間，具有相當因果關係存在。被上訴人主張其就此部分有闡明條款第4.2條第1項第4款、第6款之宥恕事由，應非可取。

３、民航局於 74年1月11日函文中要求在降落列表中應列出六至七個次列表，是否為約外要求？㈠被上訴人主張TACC規格書附表3-2載明「降落列表（In

bound List）」為4個次列表，民航局於74年1月11日函文中要求在降落列表中應列出六至七個次列表，已超逾TACC規格書之範圍，而屬約外要求云云。

㈡查TACC規格書附表3-2記載降落列表（InboundList）之

DISPLAY FORMAT為「Header - 4 symbols; 4 Subheading- 7 smybols each; 2-3 lines/subheading equaling atotal of 20 lines of 20 symbols each」（見外放TACC規格書第3-117頁），被上訴人主張TACC規格書附表3-2降落列表僅要求4個次列表，固為可取。 惟系爭航管自動化系統之建置係藉由系統分析掌握民航局之需求，基本需求規章多屬原則性的功能，細部功能必須於後續PDR、CDR階段加以確定。且GFE第18條C項已約定有關狀況顯示器格式，於簽約後二個月由民航局、洛克希德公司及其次承商舉行顯示器設計會議決定，嗣民航局於 73年7月31日與洛克希德電子公司會議中，已決議由洛克希德公司之R.Ames先生負責安排狀況顯示器列表格式及功能之討論（見本院卷十三第456頁），且洛克希德公司嗣既於74年10月8日函覆民航局同意將 「降落列表」 之次列表數量增加為6項（見本院卷十三第452頁)，則可否認係約外需求，已非無疑。

㈢此部分經送中科院鑑定結果，亦認「依據系統發展程序，

簽約時之規格說明係對系統需求作一般性的說明，而詳細需求應在後續之PDR、CDR階段中予以澄清律定。有關狀況顯示器格式定義，在合約文件中GFE 18(原證10號)有說明，簽約會後兩個月由民航局、洛克希德公司及其次承包商Magnavox舉行顯示器會議討論，律訂顯示器格式後由民航局交洛克希德公司執行設計。經查民航局回函（原證97號），乃針對審核PDR的Action ltem #36所答覆的意見，在PDR中若對原本需求有所爭議時，雙方須協調同意修訂 。

因此民航局回函(原證97號)所要求在降落列表申應列出六至七個次列表，雖與台北區管中心基本需求規章（原證85號）第3-117頁表3-2表之規定的範圍不一致（只訂定四個次列表），但仍屬合理。且經查原證106號第6六項，洛克希德公司於 74年10月8日去函民航局，表示同意接受將降落列表增加成6個次列表， 既然洛克希德公司同意接受此項需求，則民航局提出此一需求沒有超出台北區管中心基本需求規章之契約範圍。依據上述鑑定說明，民航局於其74年1月11日函要求在降落列表中應列出六至七個次列表，民航局此項要求並無超出基本需求規章範圍」（見外放鑑定報告第17、18頁）。另案成大航太所補充鑑定報告亦認「起飛列表」為合約中的基本項目，至於列表內容與多寡，為合約執行之細節問題等語（見外放鑑定報告第17頁）。既是合約執行之細節問題，則依MIL- STD-1521A規範，應於PDR、CDR中確定使用者之需求能確實反映並落實於軟體之具體設計，被上訴人主張此部分為約外需求，應非可取。

㈣縱認此部分屬約外需求，惟降落列表之次列表數量於73年

10月8日已確認增加為六項之後，嗣系爭航管契約於75年8月30日及76年9月10日進行第五次及第六次修正， 如此部分需求確有增加工期之必要，衡情洛克希德公司應無不為要求。洛克希德公司既未要求變更設計或延長工期，自難認民航局上開要求與系爭航管工程之遲延，有相當因果關係存在。被上訴人主張其得依闡明條款第4.1條、第4.2條第1項第4款、第6款規定要求展延完工期限，應非可取。

（）關於被上訴人主張「雷達資訊關連之需求曖昧不明及矛盾」部分，（中科院鑑定報告第一大項第4小項）：

１、TACC基本規格需求中關於「最佳關連」與「延遲時間」之規定，是否曖昧不明及相互矛盾？㈠被上訴人主張TACC規格書於第3.7.3.3.3.3節、第3.7.3.3

.3.3.5節雖規定需選取航跡之「最佳關連」，然於第3.2.

1.2.2節關於「遲延時間」 則規定TACC系統接收到長程雷達所偵測到之航機資訊後， 須於1秒內完成該筆航機資訊處理（其中包括選取「最佳關連」之處理）並顯示於管制員席位之顯示器，此為技術上不可能達成之要求，蓋因(1)雷達天線掃描週期之時間；(2)資料傳輸必有之延遲；及

(3)接收之眾多潛在的雷達資料， 其中之一可能即為最佳關連，而應為選取「最佳關連」之處理。上開三項因素導致在接收每一個可能的關連雷達資料間，時間之不確定性，將超過1秒。TACC基本規格需求上開關於「最佳關連」與「延遲時間」之規定，曖昧不明及相互矛盾云云。

㈡查系爭航管自動化系統之建置係藉由系統分析掌握民航局

之需求，並透過軟體之初步設計與細部設計將需求轉化為最終具體可行之軟體系統，故基本需求規章如僅就所定義的項目多為原則抽象性的功能，尚與曖昧不明有間，相關詳細需求應於後續PDR、CDR階段工作中加以確定。而系爭航管系統於邀標後，民航局給予4個月的技術澄清期限，締約雙方於簽約前已先後舉行29次澄清會議，其中27次為有關技術方面的會議，會中雙方就基本規格說明，詳為討論，若有曖昧不明或相互矛盾，被上訴人除可於上開澄清會議中請求澄清及表示其意見，嗣亦得於後續之PDR與CDR會議中與民航局研商澄清，已如前述。而所謂雷達資料關連，依指多數雷達資料間之比較，以確定何者得以最精確地偵測、預測所偵測航機之位置。而「關連處理」依TACC規格書第3.7.3.3.3.3節之規定係指： 「關連處理係將初始偵測雷達及次位偵測雷達所偵測出之特定航機之位置進行比較，以確定何資訊最能精確顯示、偵測、預測該航機之最新航路(The correlation process will compare

PSR and SSR data with eligible tracks to determinewhich data most accurately represent detections ofaircraft)」，而最佳關連依TACC規格書第3.7.3.3.3.3.5節規定係「關連處理應藉由建立航跡的預測位置搜尋範圍、使得預測時掃瞄到之數據報告落入其中一個搜尋範圍，以取得一個與時間數據配合之最佳關連(The correlationprocess shall attempt to "best" correlate associ-ated and time-corrected track datum pairs by es-tablishing search areas around the track's pre-dicted position and requiring that the datum re-port received on the scan for which the prediction

was made fall within one of the search areas.）」（見外放TACC規格書第3-290頁），而所謂「關連處理」，係指從眾多雷達資料縱中，選擇並決定那一個雷達資料為「最佳關連」、最能精準辨識出一航機位置之過程。至於「延遲時間」 ，依TACC規格書第3.2. 1.2.2節規定「TACC系統應符合以下時間需求:1.接收數位長程雷達資料和定位符號在10浬範圍外，自長程雷達傳送至顯示器上之延遲時間不得有重大延遲（少於1秒）(The TACC Automa-tion System will meet the processing time require-ments specified below.1.There shall be no signifi-cant delay (less tben 1.0 secood) between the re-ceipt of the digitized LRR data and the display of

tbe position symbol for returns from targets be-yond 10 nmi from the LRR.)」（見外放TACC規格書第3-27頁），係指收到雷達數據資料到資料傳送到顯示器上之時間，與最佳關連兩者均為數據轉換與傳送之技術問題，惟所對應之需求並不相同。被上訴人指稱二者規定曖昧不明且相互矛盾，惟其於簽約前的4個月澄清期間， 就此均未提出質疑要求澄清，其主張是否可採，已非無疑。

㈢此部分經送中科院鑑定結果，認「根據台北區管中心基本

需求規章3.2.1.2.2節與第3.2.1.4節所述，僅為雷達資料警訊顯示上的需求；而第3.7.3.3.3.3節與第3.7.3.3.3.4節所述者，為航跡關連的需求（為PSR（PrelinwinarySearch Radar)與SSR(Secondary Searcb Radar)關連之法則，並從中間獲取較為精確的資料作為目標顯示之最終結果），此二者為截然不同的需求，故並無矛盾而無法達成之處。 依據附件46號資料，3.2.1.2.2節所述雷達所測飛機資料，其航跡符號應於一秒鐘內顯示在雷達顯示幕上，此需求與原證107號之3.1.3.3.3.3所規定應做成一個最佳關聯之需求，並未相牴觸。依據上述鑑定說明，台北區管中心基本需求規章中，關於雷達資訊關連之規定第3.7.3.

3.3.4節規定與第3.2.1.2.2節、第3.2.1.4節規定二者為截然不同的需求，故並無矛盾而無法達成之處」（見外放鑑定報告第22頁）。就此本院另案送成大航太空所鑑定結果，該鑑定人亦於其補充鑑定報告說明：「控方（指被上訴人）所提出之「最佳關連」與「延遲時間」之間的問題在技術上的發展，兩者均為數據轉換與傳送上所需訂定的需求規範。在軟體上延遲時間僅唯一個單一指令的修改即可達成的，「最佳關連」與「延遲進時間」的訂定並不衝突。「識別編碼」之問題在技術上也是的簡易軟體可以包含的。對於本爭議所提之各項參數，依據技術上軟體發展過程，承包商具有爭議的參數設定為同調變，待測系統試後發現無法滿足系統功能需求時，再依實際狀況進行修改。洛克希德公司在此節骨眼中一再提出問題，顯然超乎常情」（見外放成大補充鑑定報告第20頁），被上訴人主張TACC基本規格需求中關於「最佳關連」與「延遲時間」之規定，曖昧不明及相互矛盾，並無足取。

㈣被上訴人雖以成大鑑定報告認「航空中長程雷達之技術，

雷達訊息之更新率為5秒至7秒之時間」等語，主張基本需求規章規定在只有一個最佳關連下遲延時間應少於1秒之要求，為技術上不可能達成之要求云云。惟成大鑑定報告既稱5秒至7秒為「更新率」之時間，則其所說明應者為雷達之目標獲取時間， 亦即雷達旋轉360度以獲取飛行標的之時間間隔，與TACC系統要求之雷達接受資訊後最佳關連遲延時間，乃資料處理之時間，應屬二事。況被上訴人於投標文件第二冊第1.5節稱「The LEC proposed system

is fully responsive to the TACC performmance re-quirements.The requirements are summarized intalbes 1-6 through 1-9 covering the categories ofcapacity,accuracy,response time, has track per-formance.」 （見本院卷第212至213頁，外放投標文件第二冊第1-30頁），已表明其能完全履行TACC規格書所定之執行需求，而該等需求業經列明於表格1-6至1-9。而細繹其表格1-8之內容， 明載TACC規格書第3.2.1.2.2節第1點「接收LRR資料以至顯示航跡之位置符號」 之功能性需求僅需時一秒 （見本院卷廿一第216頁，外放投標文件第二冊第1-33頁）。其於投標文件第二冊第1.5.1節亦載「

The System meets the Response Time Requirements（系統反應時間需求」，亦表明「For example,computational horsepower must be sufficient toprovide a 1-second or better response time betweenradar input and corresponding position symboldisplay.」表明其電腦運作效能須足以使系爭系統在一秒甚至一秒以內，完成接收雷達資料並顯示關連航跡之需求（見本院卷廿一第212-213頁，外放投標文件第二冊第1-30頁）。且於投標文件第二冊第3.8.1節「Time Performa-

nce Analysis（執行時間分析）」中詳列接收LRR資料、處理完畢及顯示航跡之位置符號所需各階段及執行時間，而依被上訴人分析結果，完成關連程序約需0.001秒（即1000usec）（見本院卷廿一第225頁，外放投標文件第3-149頁，Table 3-12 Function:「correlation」，Time

for processing of one Track in Microseconds：「1000 usec」），另依投標文件第二冊第3-153頁Table3-13 Data Processing timing Analysis，Total Time＝734ms（完整執行接收LRR資料、處理完畢及示航跡之全部時間為0.734秒）（見本院卷廿一第226頁），洛克希德公司更於投標文件第二冊第3.8.1.1.2節表示「SystemThroughput Performance Analysis-- The analysis in

the following paragraphs shows how LEC proposedTACC system meets or exceeds ths requirement of 1second between the receipt of degitized LRR data

and the display of the position symbol on thesituation display」，主張依其分析結果，其達成執行之時間得小於一秒（見本院卷廿一第225頁）；嗣於73年8月30日PDR會議中，更以手繪表格之方式，說明其得於

0.677秒內完成接收、處理及顯示航空器雷達資料（見本院卷廿一第229至240頁），則其主張1秒之遲延時間為技術上不可能達成之要求，並以此主張、TACC基本規格需求中關於「最佳關連」與「延遲時間」之規定曖昧不明及相互矛盾，其得依闡明條款第4.2條第1項第4、6款規定，調整完工期限，應非可取。

２、民航局於 76年8月20日函要求在TACC/1040文件第7段中列入「台北飛行情報區軍機滯空待命航線（MilitaryAircraft Holdin Pattern Within TAIPEI FIR）」是否為約外需求？㈠被上訴人主張上訴人於75年9月23日核准其所提編號TACC-

1040之作業電腦程式功能規格文件（Operational Compu-

ter Program Functional Specification）後，嗣於1987年8月20日要求將「台北飛行情報區軍機滯空待命航線（Military Aircraft Holding Pattern Within TAIPEIFIR）」列入TACC-1040文件，固有經上訴人簽署之TACC-1040文件及上訴人76年8月20日函文在卷足憑 （見本院卷十三第534至536頁、第577至580頁），惟被上訴人於另件主張上訴人違約及遲延一覽表第一大項關於上訴人所定基本需求規章曖昧不明確及違約更改工程需求項下，並未將此部分列入（見外放另案證物卷一原證34），則此部分是否確為約外需求，及被上訴人有無依民航局之要求變更設計、從事此部分之工作項目而致延誤完工期限，均非無疑。

㈡此部分經送中科院鑑定結果，認「洛克希德公司原證34號

內所顯示之內容，與『在台北飛航情報區內實施為軍事飛機暫時控制方式』之陳述並無涉及，應無約外需求之情事。根據原證124號資料顯示，民航局所提供之資料係屬『台北飛航情報區軍機滯空待命航線』資料庫之補充說明資料，非屬約外需求。依據上述鑑定說明，民航局於 76年8月20日發函給洛克希德公司要求在TACC/1040文件第七段中列入『在台北飛航情報區內實施為軍事飛機暫時控制方式』並非約外需求。」（見外放鑑定報告第24頁）。成大航太所補充鑑定報告亦認「滯空待命航線應納入原規章中」（見外放補充鑑定報告第22頁）。且被上訴人既未舉證證明洛克希德電子公司已依民航局之上開要求變更設計，自難認系爭航管工程之遲延完工，與民航局所提出上開要求間，具有相當因果關係存在。被上訴人主張其得依闡明條款第4.1條請求展延完工期限，並非可取。

（）關於被上訴人主張「完整資料欄（Full Date Block，下稱FDB）之變更需求」部分（中科院鑑定報告第一大項第5小項）：

１、民航局要求 「TCC系統完整資料欄之格式應與TACC系統完整資料欄之格式一致」，是否為約外需求？㈠被上訴人主張TACC規格書與TCC規格書就完整資料欄之格

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

㈡查完整資料欄（Full Data Block） 係顯示在台北飛航情

報區內所有管制之飛機之相關資料，民航局就完整資料欄之需求分別規定於TACC基本規格書第3.7.3.3.4.6.4.2節，及TCC基本規格書第3.7.3.3.4.4.4.2節。再查TACC規格書第3.7.3.3.4.6.4.2.1節規定TACC系統完整資料欄包含四行字母與數字構成之資訊（見本院卷十三第643、644頁，外放TACC規格書第3-315頁），而TCC規格書第3.7.3.3.

4.4.4.2.1節則規定TCC系統完整資料欄包含三行字母與數字構成之資訊 （見本院卷十三第662，665頁，外放TCC規格書第3-298頁） ，兩者所定義之完整資料欄的格式確不一致。惟TCC規格書第3.3.2節規定「The production of

the system software shall take full advantage of

any existing computer program design and code thatsatisfy requirements specified herein. New programcode shall be restricted to that which producescomputer programs satisfying the requirements ofthis specification most economically,both from aproduction and a maintenance viewpoint」，已表明系統軟體應充分利用既存之電腦程式設計與編碼，以滿足功能性需求，若自系統產製與維持等觀點，可認新程式編碼將使電腦程式最經濟地滿足基本需求規章之功能性需求時，則不在此限（見本院卷廿四第178頁，外放TCC規格書第3-64頁） ，可知關於TCC系統之軟體設計與產制，原則上應盡量以既存之電腦程式設計為基礎，以節省成本並兼顧各系統間之整合。 洛克希德公司投標文件第二冊TCC部分第1.1.2節就TCC系統之發展時程亦稱「The TCCOperational program modifications are in most casedirect copies of TACC Operational Programs which

are developed piror to the TCC PDR（TCC操作程式之修正，多數為在TCC之PDR前即已建置完成之TACC操作程式之直接複製）」 （見本院卷十六第295頁，外放投標文件第二冊TCC部分第1-19頁） 。而查洛克希德公司雖已於73年3月8日顯示器設計會議中，提出狀況顯示器之報告時敘及FDB完整資料欄（見本院卷十三第676頁），惟民航局係於 75年12月11日至12日之TCC系統PDR會議中要求TCC系統之完整資料欄之格式採用與TACC系統一致之完整資料欄之格式，斯時TCC的PDR尚未結束 ，且TCC與TACC兩系統之顯示器均由洛克希德之次供應商Magnavox公司統一製作，為兩造所不爭 ，則採用TACC之規格去設計TCC的完整資料欄，應較分別設計二不同規格之完整資料欄所需時程短，對洛克希德公司而言，將會減少系統設計之時間及成本支出，況民航局提出此項要求後，洛克希德公司及Magnavox公司均表同意，洛克希德公司甚至表明不增加額外費用（見本院卷十四第75頁），上訴人主張其係為縮短設計時間，避免耽誤系爭航管自動化系統建置之時程，而提出上開要求，尚非無據。

㈢此部分中科院鑑定結果，亦認 「依TACC及TCC工程基本需

求規章所載，兩者定義完整資料欄（FDB） 的格式的確不一致，惟 76年1月份TCC的PDR尚未結束，故民航局提出將TCC之資料欄位格式盡量與TACC之資料欄位格式一致之需求，依據MIL-STD-1521A軟體設計審查與稽核規範， 並未超出合約範圍」等語(見外鑑定報告第27、28頁)。成大航太所補充鑑定報告亦認「飛航管制系統之設計與建構，依據合約精神，各項規範必須依ICAO之附約之相關規定，

FDB 一項理應如此，洛克希德公司具備國際間數項飛航管制系統發展之經驗，理應十分了解相關規範之定義。對FDB所提之要求似乎有點吹毛求疵， 挑剔民航局的規範訂定上之缺陷」（見外放補充鑑定報告第24至25頁）。被上訴人主張此部分為約外需求，應不可取。

㈣況洛克希德公司於75年12月14日已同意民航局之上開要求

，並表明不增加費用，只要求民航局應於4週內提出詳細資料，並附帶不得增加新資料及範圍之條件，嗣經民航局於 76年1月16日發函將上開需求以書面通知台灣洛克希德公司後，洛克希德公司卻於76年8月5日去函民航局，表明將凍結TCC系統「完整資料欄」 之設計，並敘明此時任何改變將導致成本增加與完工期限延宕（見外放附件另案原證229）。足見民航局所提出上開TCC系統「完整資料欄」之變更需求，並未為洛克希德公司所接受。洛克希德公司既已拒絕民航局所為上開變更設計之要求，自無從依闡明條款第4.1條主張調整交付期限， 亦難認系爭航管工程之遲延完工，與民航局所提出上開要求間，具有相當因果關係存在。被上訴人主張就此部分有闡明條款第4.2條第1項第4款、第6款所定可宥恕之情形，亦無可取。

２、民航局要求「變更TACC系統完整資料欄之C欄與D欄」，是否為約外要求？㈠被上訴人主張TACC規格書第3.7.3.3.4.6.4.2.1節規定完

整資料欄Ｃ欄顯示內容為「Reported Altitude or Mode

C Altitude（據報高度或Ｃ模式高度）」，Ｄ欄顯示內容為「Ground Speed/Computer Identification（地面速度/電腦識別」，惟民航局於73年11月8日資料文件，要求洛克希德公司將Ｃ欄顯示內容變更為「Ground Speed/Com-puter Identification（地面速度/電腦識別）」，Ｄ欄顯示內容變更為「Assigned Altitude（指定高度）」，與TACC規格書不符，為屬約外要求云云。

㈡惟被上訴人所提所謂民航局73年11月8日資料文件上並無

民航局或其相關人員之署名，其上手寫之「from CAA 11/8/84」與文件上下方所載「73.5.2」亦不相符,且其上記載「2)PROPOSED FDB FOR TCC......Field C GroundSpeed/Computer Identificatiion Field D AssignedAltitude.....」（見本院卷十三第680頁），則民航局有為上開文件所載之要求，亦係對於TCC之完整資料欄FDB所為要求，上訴人持此主張民航局要求變更TACC系統完整資料欄之C欄與D欄之記載，已屬無據。此外，無其他有關民航局要求變更TACC系統完整資料欄之C欄與D欄記載之相關討論之文件為佐，則民航局有無提出此項要求，就此部分締約雙方有無協商討論，民航局有未依約為協力義務、洛克希德公司有無設計執行，均屬不明，被上訴人主張上訴人有提出此部分之約外要求， 其得依闡明條款第4.1條調整完工期限， 且就此部分有闡明條款第4.2條第1項第4款、第6款所定可宥恕之情形，已嫌無據。

㈢此部分送中科院鑑定時，因被上訴人未檢附相關資料，而

經中科院以「洛克希德公司在此項鑑定項目中，引用原證130號，惟原證130號自96年2月27日並未檢送， 本院於96年6月5日發函臺灣高等法院送本院所收受鑑定資料清冊，其中註明缺乏原證130號，本院曾於於97年4月25日以備科系發字第0970004662號函請臺灣高等法院協助補正，然迄97年11月30日止未收到相關鑑定資料，故不予鑑定」（見外放鑑定報告第27頁）。查本院於收受中科院96年6月5日及 97年4月25日函文後，均即檢附中科院函文影本，送達被上訴人請被上訴人補正，有本院 96年6月13日院信民勤字第0960006929號函暨送達回證、97年5月2日院函稿暨送達回證在卷足憑 （見本院卷四第53、57頁、卷五第348、350頁）。 而此部分是否屬於約外要求，及有無闡明條款第4.2條第1項各項所定情形，非經航空、通訊、資訊專業人員，以其專業依契約及相關往來文件研析，無法判斷，然被上訴人經通知後，迄97年11月30日中科院收受鑑定資料最後期限仍未補正，則被上訴人主張此部分為約外要求且有闡明條款第4.2條第1項第4款、第6款所定情形，尚屬無法證明， 其主張其可依闡明條款第4.1條要求調整完工期限及依闡明條款4.2條第1項第4款、第6款規定展延完工期限，即無可取。

３、民航局要求「TACC系統完整資料欄中之飛機識別欄（Aircraft Identification Field）增加特別連接符號」，是否為約外要求？㈠被上訴人主張依TACC規格書第3.7.3.3.4.6.4.2.1節「

Format of Alphanumeric Full Data Block（字母與數字構成之完整資料欄格式）」 規定，完整資料欄第2行即飛機識別欄係以字母數字顯示之，惟民航局於 73年12月6日函文要求飛機識別欄第一個字元應為字母，其後使用之字元應為字母數字或「-」符號，因符號「-」非屬字母數字，此部分為屬約外要求云云。

㈡查TACC規格書第3.7.3.3.4.6.4.2.1節「Format of Al-

phanumeric Full Data Block（字母與數字構成之完整資料欄格式）」固規定「The alphanumberic portion of

the FDB shall be displayed as shown below.....Thefirst line of alphanumeric data shall contain up

to six characters, the second line up to eightcharacters,...（完整資料欄之字母數字部分需依下列方式顯示……字母數字資料之第1行應包括6個以上之字元，第2行則應包括8個以上字元）」 （見TACC規格書第3-315頁，本院卷十三第644頁），惟招標文件CAA-E-1C-004「Flight Information Service System Interfact Con-trol Document（飛行資訊系統介面控制文件第5.4條message Characteristics規定:「1.The TACC automa-tion system and the AIMS shall exchange messagetraffic which uses the ITA-5 character set andcoding as shown in Table5-3.」，已明定TACC系統應使用附表5-3之字元及編碼，而附表5-3所示之ITA- 5之字元碼(character code)，除0-9之數字及a-z之英文字母大小寫外，尚包括連接「-」符號內之一些常用符號(見外放飛航資訊系統介面控制文件第5-22、5-23頁、本院卷十四第

77、78頁）。 且民航局於73年12月6日發函要求於飛機識別欄增加特別連接符號後，洛克希德公司既於 74年1月18日函覆民航局表示同意 （外放另案證物卷原證131號、第240號） ，足見民航局所為要求，並未溢出系統介面控制文件約定之範圍，則民航局於 73年12月6日函文要求TACC完整資料欄之飛機識別欄增加連接符號「-」， 應非約外要求。

㈢此部分經送中科院鑑定結果，亦認「嚴格而言 Alphanu-meric字面的意義為數字O~9: 10個數字及A-Z:26個字母。

但民航局要求在飛機識別欄加一特殊字元「-」， 確實不屬於AJphanumeric的範圍，但具電腦專業人士皆知，所謂，英文字母、數字、及特殊字元，在電腦中都以字元 （Character)方式表示，設計時實無關其為英文字母、數字、或特殊字元，都是以字元 (Character)方式呈現，係屬微小設計變動且易於執行。 民航局於其73年12月6日函中要求台北區管中心之完整資料欄之飛機識別欄加入特別之連接符號並無超出基本需求規章之規定。」（見外放鑑定報告第28、29頁）。另案成大航太所鑑定結果，亦認：「國際民航組織(ICAO)公約附件10之文字與數字顯示之規範，指定根據ITA-5之字型碼編譯資料。本編譯碼包括0-9之數字及a-z的英文字母大小寫外，另包括一些常用的符號。附件58（註：即介面控制文件第5-22至5-24頁）為合約文件，並指定以國際民航組織之規定為依據，文字及數字編碼系統為國際民航協定於飛機識別所用之一般格式。文字及數字組合之數據欄為ICAO行之多年之基本定義，在技術層面上，洛克希德公司人員應對本問題有所了解」（外放鑑定臺灣臺北地方法院80年度重訴李第506號報告影本第23頁），上訴人主張此部分為約外要求，應非可取。㈣被上訴人雖以依TACC規格書第2.6節第3點「Specifica-

tion:This specification shall have pecedence over

all subsidiary documents reference herein」之規定，主張國際民航組織文件應無適用餘地云云。惟查TACC規格書第2.6節第3點固規定「For nay cases in which thecontract, this specification, or subsidiary docu-ments are in conflict, the following precedenceshall apply:1.Contract:...2.Notes to Offerors…3.Specification:...」（見外放TACC規格書第2-4頁），惟合約文件 CAA-E-1C-004介面控制文件第5.4節既指定根據國際民航組織之 ITA-5之字型碼編譯資料，被上訴人主張國際民航組織文件應無適用餘地云云，尚無可取。

㈤此部分既非約外要求，上訴人主張其得依闡明條款第4.1

條調整完工期限，即非有據。又此部分既非約外要求，自無所謂闡明條款第4.2條第1項第6款 「超出民航局、美商洛克希德電子公司及／或其等所指定之要次承包商合理控制範圍外之事件所致之任何遲延」之問題。又民航局於73年12月6 日發函要求增加特別連接符號後，洛克希德公司隨即於 74年1月18日函覆民航局表示同意，亦難認有何闡明條款第4.2條第1項第4款所定 「民航局未能依約及時完成於本契約下之任何其他義務」之情形，被上訴人主張就此部分其得依闡明條款第4.2條第1項第4款、第6款展延完工期限，亦無可取。

４、民航局要求「顯示器上自動顯示之資料欄或係『完整資料欄』或『有限資料欄』，是否為約外要求？㈠被上訴人主張依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節「Display Eligibility and Routing

of Data Block（有限資料欄之顯示功能及路徑）」 規定「1. A LDB shall be displayed upon request for anyselected correlated SSR Or PSR datum.2.A LDB shall

be forced for display for correlated SSR or PSRdatum which has penerated a CSU's sector boundary

and altttude filter limits.3. A LDB shall beforced to all display consoles for uncontrolledemergency data. The field contatning the Mode 3/Acode shall blink. （1.有限資料欄應依據任何選出之關連初始偵測雷達或次位偵測雷達之請求顯示。2.有限資料欄應於關連初始偵測雷達或次位偵測雷達資料穿越制席位系統彊域或管制高度時顯示之。3.有限資料欄應於顯示操作台顯示非控制緊急資料）」 （見TACC規格書第3-325頁、TCC規格書第3-307~308頁、本院卷第十六卷第176至180頁）。惟參諸TACC規格書第3.7.3.3.4.6.4.2.3節及TCC規格書第3.7.3.3.4.4.4.2.3節「1.The capability shall

be provided for the display of FDBs for thosetracks assigned to a given sector....3.FDB shall

be forced to appear on the receiving CSU situationdisplay while the aircraft is in a handoff mode.

The appropriate initiate or accept handoff indica-

tor shall appear in Field E Of the FDB for theaircraft. Once an accept handoff is made by thereceiving CSU, the FDB shall be removed after aspecified time perriod (variable parameter）from

the sending CSUfs situation display.（1.在相關航跡經認定出現於特定管制空域內時，應顯示該航跡之完整資料欄。……3.在飛航器跨越管制空域時，在接手管制之席位上，應在接手時自動顯示完整資料欄……）」（見TACC規格書第3-322頁、TCC規格書第3-304頁， 本院卷十六第172至175頁），可知關於航空器航跡之相關資料，究應在狀況顯示器上表現為完整資料欄或有限資料欄，依前揭TACC與TCC規格書之相關規定， 係取決於該航跡之位置。

亦即為使航跡位置（所在區域）之管制席位能精確掌握該管制區域範圍內之該航跡相關資訊， TACC系統與TCC系統應顯示該航跡之完整資料欄FDB，否則顯示有限資料欄LDB即為已足，且在該航跡因移動而跨至另一席位所管制之空域時，為使接手管制之席位能確實掌握該航跡之資料，其狀況顯示器應自動顯示該航跡之完整資料欄FDB， 至於原管制席位之狀況顯示器，則因該航跡已脫離原管制空域，故無繼續顯示完整資料欄FDB進行管制之必要。 故而TACC規格書及TCC規格書乃規定狀況顯示器應由完整資料欄自動顯示為有限資料欄，以因應航管作業之變化與實需。

㈢依此，上訴人主張民航局於74年7月8日函稱「Each track

displayed on a Situation Display will have a datablock. If the controlling sector defined in the TEmessage data matches the sector ID of the CSU,thenthat track will have a full data bolck.Otherwise,

it will have limited data block.（每個顯示於狀況顯示器之航跡，均應具備一個資料欄。若航跡資料（TEData）中被界定之管制空域與管制空域內之航跡識別相符，則該航跡應顯示為完整資料欄，否則即顯示有限資料欄」 等語（見本院卷十三第688頁），係在說明航跡移動時應如何在狀況顯示器上顯示完整資料欄或有限資料欄，其中「若航跡資料中被界定之管制空域與管制空域內之航跡識別相符」，即指「該航跡經認定出現於特定管制空域」之意，另「否則即顯示有限資料欄」則指係「某航跡穿越至另一管制空域後，原管制空域所對應席位之狀況顯示器，應由完整資料欄自動顯示為有限資料欄」之意，不過在重申、 闡述TACC與TCC規格書有關完整資料欄之顯示要件及有限資料欄之顯示時機而已，尚非無據。

㈣此部經中科院鑑定結果認：「依據TACC基本需求中3.7.3.

3.4.6.4.3.3，其中有關LDB進入一個航管席位管制空域的疆界及管制高度範圍內，其LDB應予顯示， 在特定條件下自動顯示LDB之要求，並無超出基本需求規章之規定。 民航局要求『顯示器之每一飛機追蹤航跡必須自動地顯示資料欄或，為「完整資料欄」，或為「有限資料欄」之要求』之要求」並無超出台北區管中心基本需求規章及終端管制中心基本需求規章之規定」（見外放鑑定報告第29、30頁）。另案成大航太所鑑定結果，雖認「民航局對於本項目LDB之答覆敘述『如何界定其彊界及高度，可否需要改變…』等，顯然對軟體設計之變更輸入見解有偏差，LDB自動顯示可以在軟體中以特定規格制定，但無法設計為可以隨意調整輸入」，惟其亦認「原證132號信函（即上開民航局74年7月8日函）並未強烈涉及對顯示器之特別要求，僅對所有新出現之軌跡必須自動傳送之相關管制席位之要求……雙方爭議在於基本規章3.7.3.3.4.6.4. 3.3一節之文件資料，惟雙方所提出之資料均無法找到確實文字敘述……雙方爭議在於為LDB之顯示無法由基本規章定義具體說明，卻又各說各話，各有主張及定義」（見外放補充鑑定報告第27頁），依此，自亦難認締約雙方對此部分基本需求規章解釋上之爭議，為民航局之約外要求。

㈤且此部分縱屬約外需求，民航局於74年7月8日提出上開要

求後，系爭航管契約於74年8月8日、75年8月30日及76年9月10日進行第四、五及第六次修正，如此部分需求確有增加工期之必要，衡情洛克希德公司應無不為要求。且被上訴人亦未證明洛克希德公司已依民航局之要求變更設計，自難認系爭航管工程之工期，有因民航局之上開要求而有延誤。被上訴人主張其得依闡明條款第4.1條、第4.2條第1項第4款、第6款規定要求展延完工期限，應非可取。

５、民航局要求「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固約定：「If

Field A is left justified,the cootents of.Field Bshall be left justified within Field B.（如果Ａ欄向左對齊，Ｂ欄之內容亦應向左對齊）」、「If Field A

is right justified, the contents of Field B shall

be right justified within the available characterpositions in the third line of the data block（如果Ａ欄向右對齊，Ｂ欄之內容亦應在資料欄第三行之字元位置內向右對齊）」 （見TACC規格書第3-317頁、本院卷十三第646頁）。 而民航局固亦有於74年7月8日雷達顯示符號會議中，提出第12、13、14項要求，要求完整資料欄所包含之資料不得在其格式內左移或右移，以及由此而生之移至鄰接空白區域之資料不得產生之限制（見本院卷十三第690至694頁）。惟將完整資料欄中之資料格式固定，則洛克希德公司於設計時，即無須考量航路資料所在位置而移動相關資料，並可免除資料能左右位移功能之設計，衡情其設計難度應係降低而無增加，且應屬細部設計部分，民航局於雷達顯示符號會議中提出，難認係屬約外要求，且既係以設計難度低之要求取代難度高之要求，亦難認會致工期延誤。 被上訴人主張其得闡明條款第4.1條延後完工期限，並無足取。且嗣洛克希德公司於74年11月29日函文中表示願意接受此一修改意見 （見本院卷十三第711頁至716頁），亦難認有何 「民航局未能依約及時完成於本契約下之任何其他義務」、「超出民航局、美商洛克希德電子公司及／或其等所指定之要次承包商合理控制範圍外之事件所致之遲延」可言。

㈢此部分經中科院鑑定結果，亦認「民航局於74年7月8日會

議中提出此項要求，並無超出或改變台北區管中心基本需求規章之規定」（見外放鑑定報告第31頁），被上訴人主張其得依闡明條款第4.1條、第4.2條第1項第4款、第6款規定要求展延完工期限，應非可取。

６、民航局要求「TCC系統完整資料欄中之D欄、E欄、Z欄增加時間分配（time sharing）」，是否為約外要求？㈠被上訴人主張TACC及TCC規格書均未要求完整資料欄中之D

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

㈡民航局76年1月16日函稱「The TCC Full Date Block(FDB

）will adapt TACC Full Data Block (Ref.CAA-TACCSpecfication p.3-315), the only exception is TCC

FDB will approach type/runway in use information

on field D(Ground speed field)...」㈢查依TACC規格書第3.7.3.3.4.6.4.2.1節規定，TACC完整

資料欄之D欄顯示之資訊為「Ground Speed/ComputerIdentification」，E欄所顯示之資訊為「A ircraftStatus/scratch pad」，所顯示之資訊均不只一種，Z欄則顯示警告資訊（見外放TACC規格書第3-316頁）。又民航局76年7月30日函稱「Transmitted herwith is theCAA'S response to the subject action item: TCCFull Data Block timesharing requirements.Field Z:

...The capability shall be provided to display onealert message at a time. In the event that morethan on alert message is present,the messages shll

be alternately displayed on an equal time-sharingbasis.Field D:The capability shall be provided forRadar controllers to request/inhibit the display

of one of four alternate data sets, in all orselected FDBs, alternating with the display oftrack speed, every 2 seconds,for a selected period

of time or until inhibited....Field E: The capabi-lity shall be provided to display aircraft status

and scratch pad data, on an alternating basis,every 2 seconds,in the event both exst...」（見本院卷十三第721至722頁），細繹其意僅在敘明於D及E同一欄位顯示不同資訊之時間分配，及同時有二個以上警告訊號時，於Z欄位之顯示方式，此於一欄位處理、顯示一個以上資訊時，必需有之設計，TACC完整資料欄既規定於D、E、Z欄處理、顯示一個以上資訊，則民航局上開信函應僅在說明其時間分配，縱無此民航局函，洛克希德公司於設計時仍需處理如何於同一欄位顯示一個以上資訊之問題，就此民航局自非提出約外要求。

㈣此部分經中科院鑑定結果，認 「民航局於76年1月16日函

指示終端管制中心之完整資料欄應與台北區管中心相同之要求，係為一原則上指示。實際而言，系統於細部設計時，TACC及TCC各有不同管制任務，其中對FDB各欄位的顯示需求也會因實際情況有所不同。 故民航局於76年7月30日函中提出終端管制中心完整資料欄中之D、E、Z欄有關時間分配之需求係為合理。 依上鑑定說明，民航局於76年7月30日函中提出終端管制中心完整資料欄中之D、E、Z欄有關時間分配之需求非與終端管制中心基本需求規章第3.

7.3.3.4.3.4.2節至3.7.3.3.4.3.4.4節之規定及76年1月16日函件要求相牴觸。」（見外放鑑定報告第32頁）。 另案成大航太所補充鑑定報告亦認「合約中所謂『timesharing』 係指電腦中利用時間分割的技術，劃分出特定時段提供數據存取，以充分利用中央控制系統的操作，『分享』計算機執行上輸入與輸出的功能的時間資源。控方（指洛克希德公司）所用之『時間分配』與此意義有出入。 本項內容牽涉完整資料欄FDB中如何劃分數據進出的時間分享問題，基本上與系統軟體發展有極重要關係。控方與辯方在合約中均未詳細定義此一細節必須於執行中由雙方共同討論訂定，或由任何一方提出具體方法。……本項控方所提相關合約內容TCC CAA-A-SS-002中3.7.3.3.4.3.

4.2節為電腦識別（CID）數字的顯示，3.7.3.3.4.3.4.4節為數據追索的要求，均與本項內容無關， 原證127資料為合約3.7.3.3.4.4.4.2有關完整資料欄FDB之說明，控方所提出之資料文不對題。……本項於合約基本規章中並未有具體的定義，雙方更未就此達成協議，因此洛克希德公司應可依據最精簡的規範進行設計」（見外放補充鑑定報告第31頁）。 被上訴人主張上訴人76年7月30日函為提出約外要求，其得依闡明條款第4.1條、第4.2條第1項第4款、第6款規定要求展延完工期限，應非可取。

７、民航局要求「更改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」，為屬約外要求云云。

㈡查依被上訴人所述，TACC規格書並未要求完整資料欄E欄

顯示資料之優先順序，且民航局於73年11月8日要求TCC系統完整資料欄之格式應與TACC系統完整資料欄格式一致，則關於完整資料欄E欄顯示資料之優先順序， 自應由締約雙方於系爭航管自動化系統中之設計執行中就此細節共同討論訂定，或由任何一方提出具體方法。另案成大航太所鑑定報告亦認 「依據TCC及TACC合約內容，對所有時間分享軟體發展均未明定完整資料欄之需求或詳細優先順序，因此，依據軟體發展技術之一般規範，應為雙方於執行時依據需求由購方提出，或依據技術條件由承包商提出建議方案」（見外放補充鑑定報告第32頁）。被上訴人雖主張其已計TACC系統E欄顯示資料之優先次序為「Hold」、「Coast」及「Handoff」，並經民航局於TACC系統最後重要設計審核（CDR）核准，惟為上訴人所否認，且洛克希德公司曾於76年8月5日以LILT/JET/4589號函稱「……3.…

To display aircraft status in Field E, the prior-

ity sequence employed by Magnavox is Hold, Coast

and Handoff」（見本院卷廿一第272頁），民航局即於76年9月23日函覆「Reference:LILT/JET/4589 dated 5August 1987.......Your comment on item #3 in thereference letter has never been approved by theCAA」（見本院卷廿一第275頁），被上訴人主張其已設計TACC系統E欄顯示資料之優先次序為「Hold」、「Coast」及「Handoff」，並經民航局於TACC系統CDR核准，為無可取。

㈢完整資料欄E欄顯示資料之優先順序， 既因TACC規格書未

訂定，而應由締約雙方於系爭航管自動化系統中之設計執行中就此細節共同討論訂定，或由任何一方提出具體方法則民航局於 76年7月30日函關於TCC系統完整資料欄E欄顯示資料之優先順序說明「The priority for the air-craft status is:Coast、Handoff、Hold」（見本院卷廿一第210頁），即認難係約外要求。

㈣此部分經送中科院鑑定結果，亦認「本項欄位顯示資料的

改變，依據MIL-STD-1521A軟體設計審查與稽核系統發展之規範，民航局依據實際系統使用需求，於終端管制中心初期設計審核會議中提出更改變更狀況顯示器之顯示次序為：『海岸』（Coast）、『放棄』（Handoff）『暫停』（Hold），不超出終端管制中心基本需求規章之契約範圍，並不屬約外需求」（見外放鑑定報告第36頁）。此部分既非約外要求， 上訴人主張其得依闡明條款第4.1條調整完工期限，即非有據。又此部分既非約外要求，自無所謂闡明條款第4.2條第1項第6款 「超出民航局、美商洛克希德電子公司及／或其等所指定之要次承包商合理控制範圍外之事件所致之任何遲延」之問題。 且民航局即於76年7月30日提出要求及 76年9月23日函覆說明後，洛克希德仍於76年10月21日函拒絕民航局之要求（見本院卷十三第724頁），民航局即於76年11月16日函再為說明 （見本院卷十三第726頁） ，洛克希德公司乃於76年12月10日表示同意（見本院卷十三第728頁），亦難認有何闡明條款第4.2條第1項第4款所定「民航局未能依約及時完成於本契約下之任何其他義務」之情形，被上訴人主張就此部分其得依闡明條款第4.1條第1項第4款、第6款展延完工期限，亦無可取。

８、民航局要求「顯示軌跡之平滑數據」，是否為約外要求？㈠被上訴人主張TACC及TCC之規格書並未規定要求完整資料

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

㈡查民航局於74年7月8日雷達顯示符號會議中表示TACC系統

需能顯示目標雷達資料及軌跡之平滑數據（CAA statedthat the TACC specification calls for the display

of both target（radar datum）and track（smootheddata) displays.）（見本院卷十三第731頁），而TACC規格書第3.7.3.3.4.6.3節「Primary Surveillance Radar/Secondary Surveillance Radar Data」規定「The capa-bility will be provided to generate data for thedisplay of PSR and SSR returns.」第3.7.3.3.4.6.4節「Track Data」規定 「The capability shall be pro-vided to generate data for the display of trackdata」 ，規定TACC系統需能顯示主要/次要監視雷達資料及航跡資料（見本院卷十四第79至81頁、外放TACC規格書第3-313、3-314頁），其中第3.7.3.3.5.6.4節trackdata固未敘及smoothed data， 惟此部分是否為約外要求，及有無闡明條款第4.2條第1項各項所定情形，事涉對於所謂航跡資料（track data）之解釋，及民航局要求顯示track（smoothed data）之時程相關設計審查進行之程度等事項，非經航空、通訊、資訊專業人員，以其專業依契約及相關往來文件研析，無法判斷，尚非僅憑TACC規格書上文字的敘述所能判斷。而本件於送鑑定時，洛克希德公司此部分主張民航局之約外要求為「民航局於74年7月8日會議中提出之要求，即『目標之雷達資料及航路資料二者均須顯示』乙節，是否超出台北區管中心上述基本需求規章之規定範圍？」，係就「雷達資料」及「航路資料」二者均須顯示是否約外要求，而非就航路資料「平滑數據」之顯示是否為約外要求送請鑑定。被上訴人雖抗辯此部分確在中科院鑑定之範圍，僅是描述式不一樣云云（見本院卷十四第282頁），惟送鑑定是否為約外要求者為 「雷達資料」及「航路資料」二者均須顯示，惟被上訴人嗣主張者則為顯示「平滑數據」是否為約外要求，並未涉及雷達資料之顯示，且中科院亦係就雷達及航路資料二者均須顯示是否約外要求為鑑定，並認民航局要求目標之雷達資料及航路資料二者均須顯示，並無超出台北區管中心上述基本需求規章之規定範圍（見外放鑑定報告第30頁），被上訴人抗辯平滑數據之顯示在中科院之鑑定範圍，並無可取。且果平滑數據已包含在中科院之鑑定範圍，則依中科院之鑑定報告，此部分亦非約外要求。另案成大航太所之鑑定報告亦係針對雷達及航路資料二者均須顯示是否約外要求為鑑定（見外放補充鑑定報告第28頁），被上訴人其於中科完成鑑定，兩造為爭點協議後，始於 99年7月29日具狀主張，應認已逾時提出，如予再送鑑定單位鑑定，必有礙訴訟之終結，應認被上訴人逾時提出，本院得不再送鑑定而為審酌。且另案成大航太所之鑑定報告並認爭議雙方所提資料均文不對題，本項爭議無法找到相關基本規章定義佐證（見外放補充鑑定報告第28頁），被上訴人據成大航太所鑑定報告主張，此部分為約外要求，為無足取。準此，被上訴人主張此部分為約外要求且有闡明條款第4.2條第1項第4款、第6款所定情形，尚屬無法證明，其主張其可依闡明條款第4.1條要求調整完工期限及依闡明條款

4.2條第1項第4款、第6款規定展延完工期限，亦無可取。

９、民航局要求「TACC規格書規定之26個符號單元擴充為39個」，是否為約外要求？㈠被上訴人主張TACC規格書規定狀況顯示器符號組合中ICON

樣本組為25個符號，民航局於招標文件中修正為26個符號，惟又於74年10月22日函文中要求增加為39個，民航局此項請求為屬約外要求云云。

㈡查TACC規格書第3.7.2.2.1.2.9.12節 Symbol Display

Requirements 規定「The situation display consolesymbol generation and display requirements arespecified below....2, Repertoire. The symbol re-quirements are specified below: a.The situationdisplay console shall be capable of dislaying thesymbol set shown in Figure 3-4, or its eqivalent.

b. The symbol generation design shall incorporatemodularity to allow for changes to the symbol font

and for the incorporation of additional symbols.」，已明定在設計系統符號產生時，應納入模組以容納額外之符號（見外放TACC格書第3-125至3-126頁，本院卷十四第82至84頁），足見TACC格書已預留符號單元擴充之功能需求。又民航局於招標文件之闡明摘要雖修正TACC規格書第3.7.2.2.1.2.9.12節2.a.之Figure 3-4之situationdisplay symbol set（見本院卷十三第740至742頁），惟對於第3.7.2.2.1.2.9.12節2.b關於系統符號之設計， 應納入模組以容納額外符號之需求，並無修正，則民航局於於74年10月22日中要求增加符號為39個，是否為約外要求，即非無疑。

㈢又民航局於74年10月22日提出此項要求後，洛克希德公司

即於74年11月29日去函民航局表示同意（見本院卷十三第711至713頁），復未據被上訴人提出任何洛克希德公司就此表示爭議，或認須放原有設計將延誤工程進行之意見，則其主張系爭航自動化系統工程因民航局此一要求致有遲延，亦非可取。

㈣此部分經中科院鑑定結果，認「依據TACC基本需求規章中

3-126頁所提， 對系統符號產生設計應採模組化設計俾得容許改變Symbol Font，並得增加額外的Symbol符號， 表示在基本需求規章中已預留擴充的需求，故民航局於74年10月22日函件中，提出擴充需求並非約外需求；且依原證139號因洛克希德公司於 74年11月29日信函業已表示願接受此一修改意見，則民航局提出此一要求即非為約外要求。依據上述鑑定說明，民航局要求將基本需求規章第3-131頁至3-134頁所定之26個樣本組擴充二分之一達39個符號非為約外需求。」（見外放鑑定報告第31、32頁）。則被上訴人主張此部分為約外要求，其得依闡明條款第4.1條規定調整完工期限及依闡明條款第4.2條第1項第4款、第6款規定要求展延完工期限，應非可取。

（）關於被上訴人主張「指定跑道/使用中跑道之約外要求」部分，即民航局要求於TACC、TCC系統完整資料欄新增使用中跑道（Runways in Use）之功能，是否為約外要求？（中科院鑑定報告第一大項第6小項）：

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

２、按TACC規格書第3.7.3.2.1.46節Select Adapted RouteOptions規定「The capability shall be provided toselect an adapted route/runway option in response

to commonly experienced operational changes. Inputdata shall consist of a route point and an indica-

tor identifying which alternative is to be imple-mented. Processing shall include storing the se-lected data, reprocessing flight plan routes con-taining the changed data, and output at all af-fected CSUs, AMIS and TCCs.」 ，規定TACC系統應具備選取適當航路／跑道之選項，具備適應性的選擇能力，以因應可預見之操作變更（見本院卷十四第93頁，TACC規格書第3-197頁）；又TCC規格書第3.7.3.3.4.3.4.3節Run-

way or Approach Assignment Readout亦規定「Thecapavility shall be provided for Radar Controllers

to request/inhibit the display of runway or ap-proach data in selected FDBs alternately with thedisplay of track speed. The runway/approach datashall be displayed in place of track speed on analternating basis, at maintenance adjustable in-tervals of from 1 to 2 seconds for a selected per-

iod of time (variable parameter)of until inhibited.」，規定TCC系統應使雷建控制者能在選取之完整資料欄內要求／除去關於跑道或起飛之相關資訊（見本院卷十四第95頁，TCC規格書第3-290頁） ，是TACC及TCC系統應具備要求、選取適合航路與跑道等資訊之選項功能，以因應航空管制之實際需求。參諸洛克希德投標文件第二冊第2-50頁載「The Interactive Control Panel(ICP)allowsboth the planning and Radar control date into thesystem with minimum workload...Figure 2-16 shows

the typical layout of the interactive Display. Thefinal version of this layout will be reviewed andfinalized at the Preliminary Design Review(PDR).

The Tabular Display which emulated thie flightstrip bay information is shown in Figure 2-17. Thefinal format of this display will also be final-ized at PDR.」 明確同意多項細節將於PDR中決定（見外放被上訴人投標文件第二冊） ，上訴人主張TACC與TCC系統應具備要求、選取適合航路與跑道等資訊之選項之功能，以因應航空管制之實際要求，選取適當航路／跑道之選項功能，為系爭航管自動化系統之基本功能，其多次去函表示該項功能應具備顯示使用中跑道之功能，以確保系統操作者知悉究竟尚有何等跑道可供選取，無非在闡釋TACC及TCC規格書之內容，尚非無據。

３、被上訴人雖主張民航局於 74年5月21日函文中自承使用中跑道之功能要求為約外要求云云，惟查民航局於 74年5月21日函稱「Attached, are copies of the 'final ver-sions'of PDR Action Items 51(dated 85-04-25) and

52 (dated 85-05-15).These have been updated toreflect the agreements reached in our discussions

on 'out-of scope'item. （附件係PRD待辦事項第51及52號之最後確定版本。這些版本業已依雙方討論約外要求項目時之結論予以更新）」（見本院卷十三第903至908頁），依其文意係表示函中所述第51及52項為雙方於關於約外事項之討論中達成合意之項目，並未表示此二項即為兩造合意之約外事項。且民航局於74年5月30日並函稱「CAA'request that the "Runways in Use" Information behandled in the following mananer:......If you feelthat any part of this process is out-of-scops,then

you should follow the procedure agreed to inPlainfield document your reason for your position

and provide an estimate of the cost to implement

the out-of-scope element」，言明如洛克希德公司認此「使用中跑道」為約外要求，則應依相關程序說明理由並提出成本評估（見本院卷十三第909頁），可認締約雙方於民航局74年5月21日函所稱之會議中並未達成 「使用中跑道」 為約外需求之合意，民航局亦無以74年5月21日函表示同意「使用中跑道」 為約外要求，否則即無於74年5月30日函中告知洛克希德公司，如洛克希德公司認此部分為約外需求時應如何辦理。被上訴人據此主張民航局已於

74 年5月21日函承認「使用中跑道」為約外要求，應無可取。

４、被上訴人雖據民航局 74年5月30日函告知洛克希德公司認係約外要求，應提出關於時程／成本影響之預估之表示，主張上訴人已承認使用中跑道為約外要求云云，惟民航局

74 年5月30日函文稱「If you feel that any part ofthis prcess is out-of-scope, then you should fol-

low the procedure agreed to in Plainfield documentyour resons for your position and provide an esti-mate of the cost to implement the out-of-scopeelements,」，僅係表示如洛克希德公司認使用中跑道功能為約外要求，請依相關程序敘明理由辦理，並提出影響評估，並無任何承認使用中跑道為約外需求之表示，被上訴人據之主張此部分為屬約外需求，並無足取。

５、此部分經送中科院鑑定結果，亦認依據TACC規格書第3.7.

3.2.1.46節Select Adapted Route Options中所示「Thecapability shall be provided to select an adaptedroute/runway optioh in response to commonly expe-rienced operational changes.」此處即在說明飛機路徑/跑道改變之處理方式之功能需求，其中Select AdaptedRoute Option的功能須提供一適合航路及跑道選項，依據MIL-STD-1521A軟體設計審查與稽核系統發展規範， 民航局對此提出系統細部需求，係屬合理，故此項要求並非約外要求。依上述鑑定說明，基本規章中對於跑道之需求規定，包含民航局要求之『使用中跑道 （Runway in use）』，並無超出基本規章所規定之規格。」（見外放鑑定報告第39、40頁）。另案成大航太所鑑定報告，亦認被上訴人所提證物內容與所控違約事實內容不符，被上訴人聲請鑑定說明中所指之會議記錄未見於證物中（見外放補充鑑定報告第34頁），被上訴人主張此部分為約外要求，其可依闡明條款第4.1條調整完工期限，為無可取。

６、此部分既非約外要求， 自無闡明條款第4.2條第1項第6款所謂「任何超出民航局、美商洛克希德電子公司及／或其等所指定之要次承包商合理控制範圍外之事件所致之遲延」可言。 而民航局係於TACC初期設計審核階段之73年7月30日提及使用中跑道之功能，並於 74年9月21日待辦事項會議中提出使用中跑道之功能需求，經洛克希德公司於73年11月9日表示不同意見後，即於 73年11月21日去函說明使用中跑道為支援航路處理所必要，惟洛克希德公司仍持續於73年12月17日、74年1月28日、74年5月20日發函爭執，民航局乃於74年5月30日及5月30日函指示辦理此第51項民航局並於74年8月29日指示洛克希德公司執行 「使用中跑道」等情，業據被上訴人陳明在卷（見本院卷十三第849至850頁），並有各該信函在卷足憑（見本院卷十三第879至911頁），足認民航局對洛克希德公司之質疑與爭議，非無反應與處理，並無未為協力解決爭議之情事，亦難認有闡明條款第4.2條第1項第4項所定「未能依約及時完成於本契約下之任何其他義務」之可宥恕事由，被上訴人主張其可依闡明條款第4.2條第1項第4款、第6款展延完工期限，應非可取。

（）關於被上訴人主張「國際民航組織之程序變更之約外要求」部分，即民航局於74年10月22日函指示洛克希德修改TACC及TCC系統之設計，以符合國際民航組織文件第12版之規定，是否為屬約外需求？（中科院鑑定報告第一大項第7小項）：

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

２、查民航局確於74年10月22日去函指示洛克希德修改TACC及TCC系統之設計， 以符合國際民航組織文件第12版之規定，有該函文在卷可稽（見本院卷十三第956頁） ，惟洛克希德公司於接獲民航局指示後，即於74年10月24日去函民航局告知改版將會對系爭航管自動化系統工程之成本及工期造成影響（見本院卷十三第958頁） ，民航局旋於74年11月29日撤回該項指示（見本院卷十三第965頁） ，此項指示既經民航局撤回而不復存在，被上訴人雖主張其於接獲民航局74年10月22日指示後，即暫停相關設計工作，投入第12版文件之研究，惟未舉證，既經上訴人否認，難認其已有實際從事此項指示之相關研究設計工作，則其以上訴人有此部分之約外要求， 主張其得依闡明條款第4.1條調整工程期限，並無足取。

３、而民航局於洛克希德公司告知改版將會對系爭航管自動化系統工程之成本及工期造成影響後，旋即撤回此項要求，亦難認有闡明條款第4.2條第1項第4款、第6款所定「未能依約及時完成於本契約下之任何其他義務」或「任何超出民航局、美商洛克希德電子公司及／或其等所指定之要次承包商合理控制範圍外之事件所致之遲延」之宥恕事由，則被上訴人主張其得依闡明條款第4.2條第1項第4款、第6款規定展延完工期限，亦無可取。

（）關於被上訴人主張「顯示時間間隔之曖昧不明及擴張之約外要求」部分，即民航局於73年9月20日提出顯示時間間隔第一版規格時，要求「Clearance Processing及Transfer Alert Porcessing，是否為約外要求？（中科院鑑定報告第一大項第8小項）：

１、被上訴人主張TACC規格書第3.7.3.2.12節「Flight DataPosting Determination」中無關於顯示時間間隔（Posting Time Interval） 之規格參數，故將之列為TACC系統初期設計審核會議中待辦事項第61項，民航局於73年9月20日提出顯示時間間隔第一版規格時， 不僅未清楚定義時間閒隔之顯示規格，且增加「Clearance Processing（註：被上訴人譯為「淨空處理」，上訴人則主張係「許可處理）」及「Transfer Alert Porcessing （註：上訴人譯為「移轉警示處理」，上訴人則主張係「交管警示處理」」兩項TACC規格書第3.7.3.2.12節未規定之要求，為屬約外要求。

２、查TACC規格書第3.7.3.2.12節「Flight Data PostiagDetermination」規定：「....1. A capability shall

be provided to generate and out five differenttypes of flight data: a. Inbouod coordination;b.Departure coordination; c. Arrival coordination;

d.Active en route; and e.Terminal area overflight.....」、第3.7.3.2.12.1節Inbound CoordinationFlight Data 規定：「Inbouod coordination flightdata shall be output at a specified time interval(variable parameter) prior to the estimated bound-

ary crossing time for the adapted point identified

as the boundary crossing point...」、第3.7.3.2.12.2節「Departure Coordination Flight Data」、第3,7.3.2,12.3節「Arrival Coordinaiation Flight Data」、第3.7.3.2.12.4節「Active En Route FFliaht Data 」、第3,7,3,2,12.5節「Terminal Area Overflight FlihtData」亦均規定「data shall be output at a specifi-

ed time interval (variable parameter)」(見外放TACC規格書第3-250至3-253頁），是TACC規格書第3.7.3.2.12節規定TACC系統應能產生並輸出歸航協調、起飛協調、抵達協調、主動航路及終端區域領空飛越五種不同類型之飛航資料，並規定各類飛航資料輸出之時間間隔（TimeInterval）。TACC系統所應產生並輸出之飛航資訊，另TACC規格書第3.7.3.2.1.10節「Current Flight Plan（現行飛行計畫）」規定：「The capability shall beprovided to enter the actual cleared flight intent

and the last available estimated boundary time.

The current flight plan data shall include flightplan data as cleared by the controlling center,SSRcode assigned, and boundary estimate... ..Theacceptance of current flight plan data shallresult in output at the CSUs, AMIS position, TCCs,

and co the FISS, as appropriate.」（見外放TACC規格書第3-180至3-181頁，本院卷十四第100至101頁），可見TACC規格書所定現行飛行計畫之資訊，係指飛行計畫經管制中心許可後（cleared by the controlling center），TACC應能將已經許可之航空器意圖（actual clearedflight intent）等資訊適時傳輸至TCC系統，故關於航空器已經許可之資料，應亦屬TACC系統所處理之飛航資訊。

另TACC規格書第3.7.3.2.16.1節Flifht InformationRegin Boundary Crossing Fix/Time Determinatiion（跨越飛航情報區之之位置/時間決定）規定：「Theboundary crossing fix will be defined as theintersection of the route of flight and FIRboundary. The bouodary crossing time for inboundflight will be estimated by the adjacent FlR andtransmitted to the Taipei FIR. The boundarycrossing time for outbound flights shall beestimated by the fix-time estimation function andtransmitted to the appropriate FIR a specifiedinterval (variable parameter) prior to theestimated boundary crossing time....」（見外放TACC規格書第3-262頁，本院卷十四第103頁），則TACC規格書之「Flifht Information Regin Boundary CrossingFix/Time Determinatiion」 規定係指飛航器飛越台北飛航情報區之過程中，在進入台北飛航情報區時，應由前個飛航情報區估算其時間並將資料傳送到台北飛航情報區，該飛航器離開台北飛航情報區之時間及位置，則應在預估飛越之時間前，於特定時間間隔下，傳送至其即將進入之下一個飛航情報區，故關於「跨越飛航情報區之位置／時間決定」及與之相關之更新傳遞功能，亦屬TACC系統所應處理之飛航資訊。TACC規格書第3.7.3.2.12節「飛航資料顯示」既規定飛航資料有顯示時間間隔，TACC規格書第3.

7.3.2.1.10節「現行飛行計畫」與第3. 7.3.2.16.1節「跨越飛航情報區之位置/時間決定」 亦有應適時傳輸或顯示時間間隔之要求。 則上訴人主張民航局於73年9月20日提出顯示時間間隔規格時，一併說明ClearanceProcessing及Transfer Alert Porcessing等亦有時間間隔之要求存在，提醒被上訴人於設計時應納入考量，並非提出約外要求，尚非無據。

３、被上訴人雖主張幾經雙方討論、澄清後，民航局於 74年8月29日要求執行Clearance Processing及Transfer AlertPorcessing之顯示時間最終版規格，洛克希德公司於74年9月4日覆函表示此涉及闡明條款4.3條之變更指令，民航局未予否認，應認已承認「Clearance Processing」及「Transfer Alert Processing」 為約外要求云云，惟為上訴人所否認。查洛克希德公司固於74年9月4日函表示此部分涉及闡明條款4.3條之變更指令， 要求民航局依闡明條款第4.3條規定之程序辦理（見本院卷十三第1063頁），民航局固未就洛克希德公司之上開函文為回應，惟默示之意思表示與單純之沉默有別，單純之沉默除經法律明定視為已有某種意思表示外，不得即認係表示行為，被上訴人並未舉證民航局嗣有依闡明條款第4.3條規定之程序辦理，其以此主張民航局已承認此部分為約外需求，應非可取。

４、被上訴人雖又以其嗣已將顯示時間間隔之最終規格版本納入電腦程式功能設計文件，即TACC-1140與TACC-1110之作業電腦程式功能規格文件，民航局於 75年8月16日核准上開TACC-1110文件，而該文件第5.2節表示已「The FDPsubfunction, while not required by CAA-E-SS-001,will satisfy a requirement dervied from the reso-lution of PDR Action Item 61 as its relates to thetime at which postings are to be displayed, and atwhich Transfer Alerts are to be transmitted （飛航顯示資料次功能，雖並未規範於TACC規格書，但將滿足依據PDR待辦事項第61項之決議所提出之需求）」 ，故民航局已承認此部分為屬約外需求云云。惟TACC-1110 文件第

5.1條「PURPOSE（目的）」記載「The purpose of the

FPD subfunction is to scan the Flight Posting datebase and select those posting data records whichshould be displayed immediately. The flight post-

ing date records themselves will be generated by

the Flight Plan Porcessisng, TACC-1110,function

The FPD subfunction will notify the FPP functionwhich posting data records are suitable for imme-diate display. The FPD subfunction will not trans-

mit the posting data records to the Planning Con-troller's Display.」，揭示PDR待辦事項第61項所示FDP子功能之目的在瀏覽飛航顯示資料並選擇何者適於立即顯示，並於附件Ａ明定待辦理事項第61項之功能為「飛航顯示之週期性瀏覽」（見本院卷十四第182至186頁）。民航局嗣於核准TACC-1110文件中，說明待辦事項第61項之重點在於「適當之顯示間隔」（見本院卷十四第187頁），足見TACC-1140文件「The FDP subfunction,while notrequired by CAA-E-SS-001, will satisfy……」之意，係指「Clearance Processing」及「Transfer AlertProcessing」之功能性需求，在TACC規格書中僅有「應適時傳輸」或「於特定時間間隔傳輸」之概括性描述，尚未落實於具體設計而言，尚難以此認民航局承認此部分為約外需求。

５、此部分經送中科院鑑定結果，亦認「通常顯示時間的間隔係以建成系統建置目的為主要的考量依據，而設定顯示間隔可降低系統設計的複雜度。……關於ClearanceProcessing及Transfer Alert Porcessing之需求，實為TACC基本需求規章第3.7.3.2.12 Flight Data PostingDetermination所提之細部設計說明，並非約外要求。」（見外放鑑定報告第42至43頁）。

６、此部分既非約外要求，則被上訴人主張其可依闡明條款第

4.1條調整完工期限，自屬無據。 又此部分既非約外要求，自無闡明條款第4.2條第1項第6款所謂 「任何超出民航局、美商洛克希德電子公司及／或其等所指定之要次承包商合理控制範圍外之事件所致之遲延」可言。又依中科院鑑定報告所載本項爭議緣由之記載：「本項爭議緣由在73年8月7日執行TACC PDR時 ，雙方決定PDR待辦事項第61項，由民航局提供飛航資料顯示時間間隔。但民航局在答覆此PDR待辦事項第61項時，於73年10月3日給洛克希德公司的信函中，除提供相關飛航資料顯示時間間隔資料外，另外提及有關Clearance Processing及Transfer AlertProcessing相關敘述。洛克希德司認為此二項為超出TACC基本需求規章範圍而新增加的功能，故於 73年11月9日去函民航局，表示就民航局所要求的此二項功能，認已超出TACC基本需求規章範圍而不予接受。洛克希德公司嗣後於74年1月28日向民航局提議PDR待辦事項中某些功能應可接受，某些則建議刪除。 但其中卻明白註明排除PDR待辦事項第61項。民航局於74年3月7日去函洛克希德公司提出針對PDR待辦事項第61項回覆的修訂版本， 表示洛克希德公司及OAO公司一直未對此爭議事項參與研討， 並期待其能儘早審查此一修訂版本，藉以平息爭端。但洛克希德一直未對此事項再作回應， 於是民航局於74年5月15日去函洛克希德公司， 將定案的PDR待辦事項第61項送交洛克希德公司。 最後民航局於74年8月29日去函洛克希德公司，指示洛克希德公司依待辦事項最後版本， 執行PDR待辦事項第13、51、52、61項及一般待辦事項第72項」等語，亦難認民航局有闡明條款第4.2條第1項第4項所定 「未能依約及時完成於本契約下之任何其他義務」之情形，被上訴人主張其可依闡明條款第4.2條第1項第4款、第6款展延完工期限，亦非可取。

（）關於被上訴人主張「有限資料欄（Limited Data Block）之使用定義不明及矛盾」部分（中科院鑑定報告第一大項第9小項）：

１、被上訴人主張洛克希德公司進行有限資料欄（LDB） 之設計需要：㈠LDB應為主動或被動顯示？㈡當一個LDB產生時，該LDB應包含全部或單一航跡？ ㈢是否僅限於某航管人員管制彊域內之航跡，始應顯示LDB，或全部航跡均需以LDB之方式，顯示於每位航管人員之狀況顯示器內？ ㈣是否僅非管制航跡始顯示LDB？或管制航跡亦須顯示LDB？㈤是否僅相關連的航跡始須顯示LDB？或非相關連之航跡均須顯示LDB？等上列五項資訊。但TACC規格書關於有限資料欄之顯示條件規格不明及相互矛盾，致洛克希德公司無法據以進行設計云云。惟被上訴人於本件送請中科院鑑定時，就其主張TACC規格書關於有限資料欄之顯示條件規格不明及相互矛盾致洛克希德公司無法據以設計而請求鑑定之情形為：㈠TACC規格書第3.7.3.3.4.5.1.3節第4項未說明應涵蓋那些tracks及tracks彼此間是否應該互相呼應。

㈡TACC規格書第3.7. 3.3.4.6.4.3.3節之規定是否應僅適用於In-sector或是全部tracks之位置，且未說明tracks須否具備controlled之功能。㈢TACC規格書第3.7.3.3.4.

6.4.3.3節第2項未說明應使用controlled或uncontrolled之tracks（見外放對於「航空管制自動化系統」鑑定事項之說明第55頁），並不包含 「LDB應為主動或被動產生？」及 「是否僅相關連的航跡始須顯示LDB或非相關連之航跡均須顯示LDB？」,故此二項並不在中科院鑑定之範圍，而依成大航太所鑑定報告所載，且此二項亦不在成大航太所鑑定範圍內（見外放補充鑑定報告第41頁）。被上訴人於中科院出具鑑定報告後始為主張，而TACC規格書關於有限資料欄之顯示條件，是否有 「LDB為主動或被動產生」及 「是否僅相關連的航跡始須顯示LDB或非相關連之航跡均須顯示LDB」 規定不明或相互矛盾，尚非僅憑TACC規格書一、二小節之規定即可判定，非經航空、通訊、資訊專業人員，以其專業依契約及相關往來文件研析，無法判斷。然本件訴訟自上訴人於78年間提訴迄今已逾20年，被上訴人於85年及91年另案送請成大航太所鑑定，及95年本院送請中科院鑑定時，均未爭執此部分，請求併予鑑定，於95年3月至98年8月中科院鑑定期間，亦未追加請求鑑定，則其於中科完成鑑定，兩造就系爭航管自動化系統有無闡明條款第4.1條及4.2條第1項各項事由為說明及論述時，始於99年10月11日具狀主張此一爭執事項，應認已逾時提出，如再送請鑑定單位鑑定，必有礙訴訟之終結，本院得不再送鑑定而為審酌，被上訴人此部分之主張，尚屬無法證明，而無可取。

２、查TACC規格書中關於有限資料欄（LDB）之顯示條件規定於第3.7.3.3.4.5.1.3節第4點，及第3.7.3.3.4.6.4.3.3節。其中第3.7.3.3.4.5.1.3節第4點規定：「Upon re-quest by the Radar Controller,the capability shall

be provided to display LDBs for each uncontrolledtrack which is within that CSU's geographic andaltitude filter limits（在雷達管制員要求時，系統應能顯示地區轄區及高度範圍內每個非管制航跡之有限資料欄）」（見外放TACC規格書第3-301頁），第3.7.3.3.4.6.4.3.3節規定：「1.A LDB shall be display upon re-quest for any selected correlated SSR or PSR datum

2.A LDB shall be forced to display for correlated

SSR or PSR datum which has penetrated a CSU'ssector boundary and altitude filter limits.3.A LDBshall be forced to all display consoles for uncon-trolled emergency data.The field containing theMode 3/A code shall blink （1.於受請求時應就任何選出之關連次位偵測雷達或初始偵測雷達資料，顯示一個有限資料欄。2.應於關連次位偵測雷達或初始偵測雷達的資料進入管制席位系統之彊域或管制高度時，應顯示一個有限資料欄。3.……」（見TACC規格書第3-325頁）。 其中第3.7.3.3.4.5.1.3節第4點已說明有限資料欄所涵蓋者為「uncontrolled track」（非管制航跡），第3.7.3.3.4.

6.4. 3.3節第3點亦明確規定有限資料欄所顯示者為「un-controlled emergency data」，並無矛盾或定義不明或曖昧之情形。

３、又依上開TACC規格書第3.7.3.3.4.6.4.3.3節第2點規定，有限資料欄自動顯示之時機，為航空器航跡脫離特定席位管制空域時，而依TACC規格書第3.7.3.3.4.5.1.3節第2點「2.The capability shall bo provided to automati-cally display FDBs for all controlled tracks which

are under that CSU's control regardless of geogra-phic or altitude filter selection.…4.Upon request

by the Radar Controller, the capability shall beprovided to display LDBs for each uncontrolledtrack which that CUS's geographic and altitudefilter limits.」之規定（見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節為其中之一小節，洛克希德之投標文件亦載「The radar controller

at the SD can enter and control the amount of data

on the display by using his keyboard and displaycontrol functions.（狀況顯示器前之雷達控制員，得在顯示器上進入並控制顯示器資料之數量……）」（見本院卷十六第23頁）。而航管人員管制區域內（In-sector）之顯示器係指規定於TACC規格書第3.7.2節之計劃管制席位（Planning Controller Position）使用之列表顯示器（In sector tabular display）， 兩者為不同席位功能，洛克希德公司投標文件除上開SD功能外，亦另設有「tabular and information Display」章節（見本院卷十七第30頁），且於洛克希德公司投標文件上此二者亦各有其不同之顯示器圖示（見本院卷十六第31至33頁），並無所謂適用關聯問題。

５、就此部分中科院鑑定結果，亦認「台北區管中心基本需求規章第3.7.3.3.4.5.1.3節第4項已明確說明應涵蓋顯示雷達管制員地區轄區及高度範圍內每一Untrolled Track之有限資料欄，……在此節中敘述有限資料欄顯示相關功能，實與track間的呼應（correlated）並無任關係。……經查，台北區管中心基本需求規章第3.7.3.3節全節係說明雷達資料處理雷達席位所使用的雷達狀況顯示器功能。而In-sector係指計畫管制席位 （Planning ControllerPosition）使用的顯示器；兩者為不同席位功能，實無所適用關聯問題。……顯示慣例上，一般均採用明定必需要顯示的項目及其他顯示選項，由雙方提供之證物，雖未提及Controlled與Uncontrolled之定義，但3.7.3.3.4.6.3.3之有限資料欄的顯示條件無關 Controlled 或 Uncon-trolled，而由3.7.3.3.4.5.1.3-4之內容應表示除已顯示的資料外，雷達控制員還可以要求在地理與高度範圍限制內顯示Unxcontrolled Track的資料。 因此，此項要求並未明顯違反顯示慣例及有限資料欄使用的時機且無明顯的予盾……依上述鑑定說明，本小項『有限資料欄之使用定義』並無模糊不明而達一般包商無法據以完成設計之程度」（見外放鑑定報告第44至45頁）。

６、被上訴人雖主張洛克希德公司於73年7月31日TACC之PDR會議中，已就此部分其認為矛盾及曖昧不明之處，與民航局討論（見本院卷十五第103頁），嗣又於74年7月8日會議中請民航局提出澄清說明（見本院卷十五第107至112頁），民航局於74年7月8日函中自承現行文件（即TACC規格書）並未清楚定義狀況顯示器資料欄之顯示（見本院卷十五第113至114頁） ，洛克希德公司乃於75年1月14日依雙方多次討論之意見，撰寫有限資料欄之設計說明（見本院卷十五第115至126頁） ，經民航局於75年2月20日函覆始告確定（見本院卷十五第127至132頁），嚴重延誤系爭航管工程之進度，而有闡明條款第4.2條第1項第4、6款之適用云云。 惟查，依被上訴人所述，洛克希德公司於75年1月14日依雙方討論之意見，撰寫有限資料欄之設計說明後，民航局即於 75年2月20日函覆意見而告確定，應無未即時完成依契約所負義務之情形。 至於73年7月31日洛克希德公司提出問題起至洛克希德公司提出設計說明前之期間，既經洛克希德公司與民航局多次討論，被上訴人亦未舉證民航局有如何故意拖延，或不依約為協力，亦難認自洛克希德公司提出討論，迄其完成設計說明期間，民航局有何未能依約及時完成於系爭契約應盡之義務之情形，被上訴人主張其得依闡明條款第4.2條第1項第4款展延完工期限，並無可取。又系爭航管自動化系統係採由上而下之建置方式，由洛克希德公司負責將被上訴人之需求轉換為具體可行之設計藍圖，故其規格書僅為原則性的規格描述，非詳敘各功能細節。民航局於簽約前既曾召開29次澄清會議，由雙方逐頁、逐條、逐句訂論基本規格說明，如規格書確有相互矛盾或曖昧不明之處，即可於27次澄清會議中澄清。且若基本需求規章中仍有任何不足或敘述不清之處，雙方仍可於PDR中再提出澄清，亦難認有何闡明條款第4.2條第1項第6款所定「任何超出民航局、美商洛克希德電子公司及／或其等所指定之要次承包商合理控制範圍外之事件所致之任何遲延」之情形，被上訴人主張其可依闡明條款第4.2條第1項第6款展延完工期限，亦無可取。

（）關於被上訴人主張「飛機識別欄之定義不明」部分（中科院鑑定報告第一大項第10小項）：

１、民航局指示飛機識別欄第一個字元亦可為字母、數字或符號「-」，是否為約外要求？㈠被上訴人主張民航局於 73年12月6日要求TACC系統完整資

料欄中「飛機識別欄」格式，增加連接符號「-」 之約外要求，且民航局與洛克希德公司於73年12月20日之介面控制會議已達協議，飛機識別欄（Air craft Identifica-tion）第一個字元應為字母，詎民航局於 74年7月19日要求飛機識別欄第一個字元亦可為字母、數字或符號「-」，73年7月3日要求飛機識別欄第一個字元應包括字母、數字，違反雙方73年12月20日之協議，為屬約外要求云云。

㈡查民航局於73年12月6日要求TACC系統完整資料欄中 「飛

機識別欄」格式，增加連接符號「-」，並非約外要求，已如前㈤３所述。又招標文件CAA-E-IC-004,Rev.1「Preliminary Taipei Area ControlCenter AutomationSystem/Flight Information Service System InterfaceControl Document（以下稱飛行資訊系統介面控制文件）」第5.4條已明定TACC系統應使用「Table 5-3」所示之ITA-5字型碼交換訊息，「Table 5-3 」所列之ITA-5字型碼除0至9的10個數字及A到Z之英文字母外，尚包括連接符號「-」等常用符號，已如前述。而TACC規格書第2.4節與TACC／FISS介面文件ICD-004第2.1節明訂國際民航組織相關文件ICAO-Doc No.444-RAC/501/10為系爭航管自動化系統之合約應用文件（見本院卷十六第34至38頁），而該文件附錄二關於飛機識別之資料，則舉例「EIAKO」、「4XBCD」及「N2567GA」 （見本院卷十六第38至39頁），其中「4XBCD」 即係以數字為第一個字元。上訴人主張民航局指示飛機識別欄的第一個字可以為數字，應非屬約外要求，尚非無據。

㈢又民航局於74年7月19日函稱「CAA informed LILI in

letter LD-0000000 that the first character of theAIR- CRAFT ID（as displayed in the Full DataBlock）is an alpha character」，指示飛機識別欄第一個字元為字母（見本院卷十五第158頁），於76年7月3日則稱「the initial character of an AID may be a digit」，主張飛機識別欄第一個字元亦可為數字，固有不同，惟字母及數字既均為契約文件規定飛機識別欄可使用之字元，而系爭航管自動化系統採由上而下之建置方式，細節之設計由締約雙方於設計審查會議中澄清，自難以民航局先後之意見有所不同，即認後者為約外要求。

㈣被上訴人雖主張雙方於73年12月20日之介面控制會議時已

達成飛機識別欄第一個字元為字母之共識，惟為上訴人所否認。查被上訴人74年1月18日函固稱「Further,it hasbeen agreed that the firmst character must bealpha(A-Z)……The foregoing information is in con-firmation of that given verbally to CAA at a jointmeeting on 20 December 1984.」等語（見本院卷第十五第156頁） ，惟此為被上訴人單方製作之文書，被上訴人復未提出73年12月20日之會議紀錄佐證，既經上訴人所否認，自難逕以此認雙方已達成飛機識別欄第一個字元確定為字母之協議。又民航局73年12月6日函固稱「the CAA'sformat for this field contains an alpha character

in the first character followed by one to sixcharacters that are alphanumeric and/or the spe-cial character"-"」（見本院卷十五第154頁），惟此係民航局於介面控制會議前表達之意見，雙方是否確於介面控制會議中討論所獲致相同之結論，尚非無疑。

㈤此部分經中科院鑑定結果，亦認「依據台北區管中心基本

需求規章有關字母數字完整資料欄之格式，已說明FDB 顯示其內容由字母數字組成，故民航局於其74年7月3日函中指示飛機識別欄第一字亦可為數字乙節，非屬約外要求（見外放鑑定報告第47頁）。另案成大航太所鑑定報告亦認「文數格式之排列，在指定的位元數目內恰巧可以形成個獨立字元，應為程式設計技巧上的問題，與基本規章3.7.

3.3.4.6.4.2.1節之敘述無關。 相關技巧可以為文字與數字互換，或將符號與文字或數字更換。……有關飛機識別為飛航管制系統極重要的項目，國際間的規範明確，且有範例可依循。合約基本規章已經做明確說明，並提供航管與戰管間的差異。……控方（指被上訴人）對於辯方所提增加『-』 之技術深度與所需工時均非所陳述之困難，應做之修改與提升對本系統原合約中戰管與航管協調具效益有積極意義，控方自己理解」等語（見外放鑑定報告第43至44頁）。被上訴人主張此部分為約外要求，並主張其等依闡明條款第4.1條規定調整工期，應非可取。

㈥此部分既非約外要求，則被上訴人就系爭航管自動化工程

之遲延自與闡明條款第4.2條第1項第6款所謂 「任何超出民航局、美商洛克希德電子公司及／或其等所指定之要次承包商合理控制範圍外之事件所致之遲延」無關。又此部分既非約外要求，被上訴人復未證明締約雙方已協議確定飛機識別欄第一個字元必須使用字母，則民航局嗣指示飛機識別欄第一個字元亦可為數字，亦難認有何民航局未能依約及時完成契約之義務之可言，故而被上訴人主張其可依闡明條款第4.2條第1項第4款、第6款展延完工期限，亦無可取。

２、民航局於74年3月20日函要求刪減電腦訊息格式由7個字元變更為5個字元，是否為約外要求？㈠被上訴人主張TACC規格書第3.7.3.3.4.6.4.2.2節規定：

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

㈡查TACC規格書第3.7.3.3.4.6.4.2.2節「Contents of

Alphanumeric Full Data Block」第2點固約定「2.Field

A : Field A shall consist of eight character posi-tions and shall be diviede into two parts.Charac-

ter position A1 through A7 shall contain the air-craft indentification/call sign;...」（見本院卷十五第151頁，TACC規格書第3-317頁），惟參諸TACC規格書第3.7.3.3.4.6.4.2.1節「Format of Alphanumeric FullBlock」規定「……The numeric subscript indicates

the character position in the field.The first line

of alphanumeric data shall contain up to six char-acters, the second line up to eigh characters....」 ，就完整資料欄格式所組成之字元數，第一行不超過6個（Z1-Z6），第二行不超過8個（A1-A8）之規定 （見本院卷十五第149頁，TACC規格書第3-315頁），完整資料攔之Ａ欄所含字母數字，最多既以8個為限，則不問Field A之飛機識別欄之字元為5個或7個，應均未逾TACC規格書之約定。且招標文件CAA-E-IC-001,Rev.2「PreliminaryTaipei Area ControlCenter Automation System/AirDefense Center Interface Control Document」（航路與防空自動化系統之銜接控制文件，以下空防介面控制文件）第1.3條規定「The functional capability and thedesign of the TACC.Automation System--Air-DefenseSystem interface are constrained by decisionswhich are made to meet the basic objectives of theinterface. These constraints are:1.Interfaces will

be designed such that the cost impact on devicesthat must meet the interface requirements is kept

to a minimum. 2. Existing standards shall be usedwhenever possible in establishing the interfacerequirements……（TACC與空軍之系統間介面之功能，應受介面之基本目標所限制：1.介面之設計，應在符合介面要求之前提下，將成本上之衝擊降至最低。2.既存之標準應在建置介面要求時，盡量援用）」（見外放空防介面控制文件第1-2頁），可知洛克希德公司在建置系爭航管自動化系統時，應使其與空軍之系統相容。而空軍之ADC系統，於兩造簽訂爭航管自動化系統建置契約前，早已為運作中之系統，則上訴人於74年3月20日函中表示ADC系統僅能接受5個字元數之飛機識別欄，請洛克希德公司列入設計考量，應不屬約外之要求。

㈢此部分送請中科院鑑定結果，亦認「根據合約文件TACC/

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

㈣此部分既非約外要求， 自無闡明條款第4.2條第1項第6款

所定 「任何超出民航局、美商洛克希德電子公司及/或其等所指定之要次承包商合理控制範圍外之事件所致之遲延」之情形。又被上訴人雖主張民航局未依GFE第12項b款規定之期限，於簽約後5個月內，即73年5月20日前，提供空軍戰管系統ADC電腦訊息格式之最終版本， 其得依闡明條款第4.2條第1項第2款、第4款展延完工期限云云，惟查，依GFE第12項「Data Formats for Interface Planning」所載「Need preliminary data as soon after ContractAward Final 5 MAC」之規定，上訴人僅需提供初版之ADC電腦訊息格式版本予洛克希德公司 （見本院卷十六第216頁），被上訴人主張民航局應於73年5月20日前提供ADC電腦訊息格式之最終版本，已無可採。 而民航已於73年1月18日提供介面定義予洛克希德公司，並經洛克希德公司簽收在案（見本院卷十六第217至218頁） ，其後並於73年3月3日以前將GFE第12項所定文件全數交付洛克希德公司，此觀民航局73年3月3日函稱「1.The CAA had delivered

to the LILT during the period of 18 January, 1984

to 3 March 1984, all the availble inerface data asspecified in GFE 12. Attachments A through C arecopies of LILT's signed receipt」，及73年3月9日顯示設計會議紀錄載「2.The existing ADC test andserviced messages were forwarded to Lockheed (Mr.

Joe Johnston)by the CAA(Ms.JeanShen)....8.GFE Item12f was given to Lockheed (Mr.Don Kinndy) by CAA(

Ms.Jean Shen）」可明（見本院卷十六第219頁、第221頁）。 且兩造於74年8月8日第4次變更契約之附件3關於GFE第12項b款之「Display Format Definition」亦載「Re-ceived Display Conference Completed Mar 1984」（見本院卷廿一第319頁） ，被上訴人主張民航局未依期限提供空軍戰管系統ADC電腦訊息格式之最終版本， 其得依闡明條款第4.2條第1項第2款、第4款展延完工期限云云，亦無可取。

（）關於被上訴人主張「單機飛航操作說明之約外要求」部分，（中科院鑑定報告第一大項第11小項）：

１、被上訴人主張系爭航管系統工作說明書（SOW）第5.7節規定，洛克希德公司應提供文件，以Contract Data Requi-rements List（契約文件清單規範，以下稱「CDRL」）所規定者為限，而CDRL並未將「single-thread operationdescription」 列為洛克希德公司應提供之文件，民航局於73年3月9日提出single-thread operation descripti-on之第一版，要求洛克希德公司增列於洛克希德公司ATC-1000設計文件，為屬約外要求。且民航局自73年3月9日至77年6月25日先後提出7個版本，其中並包含多項約外要求， 而有闡明條款第4.1條、第4.2條第1項第4、6款之適用云云。

２、查關於 「single-thread operation description，以下稱STOD（被上訴人譯為『單機飛航操作說明』，上訴人則譯為『航管作業流程說明』」，就此，締約雙方曾於73年3月間舉行之顯示器設計會議中由民航局並提出其版本予洛克希德公司參考，並由Mr.Peter Hou 及 Mr.EdwardTseng進行簡報（見本院卷十五第228至241頁）。 而所謂STOD，係指航班起降時（departureand arrival）管制標準作業流程之概稱，明確律訂飛機起降之程序、時機、與塔台間交換之資訊、塔台應提供之服務或下達之指令等涉及飛航管制之程序或細節，乃系爭航管自動化系統設計時所應參酌之重要事項，已據上訴人所陳明。縱依被上訴人所述，STOD為乙架飛機進入、穿越或離開台北飛航情報區時，航管人員所進行各項航空控制行為之說明，核亦應屬系爭航管自動化系統作業流程之一部分，而非某種新的操作需求。又CDRL中雖未明定上訴人應提出「STOD」，惟觀兩造就此之信函及設計文件，亦有使用 「Single ThreadScenario」、「Operational description」、「CAAspecification/ single thread description」（見本院卷十五第275、303、401、403頁），上訴人主張STOD僅為概稱，與前開「Single Thread Scenario」等均泛指航管作業流程尚非無據。

３、而CDRL 010「Computer Program Confiquration ItemDevelopment Specification（電腦程式結構項目發展規格，以下稱CPCI）」之Preparation Instructions中，規定CPCI發展應先建立程式設計與發展之執行標準（per-formance criteria），CDRL 010第1.2節與第3節則規定，被上訴人應以簡要描述敘明全部電腦程式之功能性摘要，且須詳述電腦程式之執行需求，並界定所有之功能性需求、設計限制與必要標準（見本院卷十六第287至289頁），足見被上訴人之設計文件須對全系統之程式如何運作，進行簡要之描述。而CDRL 010第3.2.1節「…Operatorcontrol requirements shall be detailed, includingnames and description of operator actions,consoles

or operator positions where applicables,and therequired programmed restrictions」，規定操作控制需求應予具體化，包含操作員之名稱、描述、所適用之席位或操作位置（見本院卷廿一第333至334頁，外放CDRL第4-45至4-46頁），故為使系爭航管自動化系統之設計符合航管需求，被上訴人即需以STOD作為設計系爭航管自動化系統如何運作之藍圖。且被上訴人提出之STOD設計文件ATC-1000首頁記載「CRDL Item 010」為執行依據，並於內文第6-1頁記載「The talbe formats include descriptio-

ns for the two major operational CPCIs:the FDP and

the RDP. The operational narrative assumes thesystem is powered up,initialized and operatingnormally without fialure....（後述表格包含系爭航管自動化系統之二大操作CPCIs，即FDP與RDP。 相關操作性敘述係假設系統正常開機、啟動運作……）」（見本院卷十五第301、303頁），上訴人主張此STOD非約外要求，應為可取。

４、被上訴人雖主張72年12月20日締約時，已明訂以民航局對招標文件之闡明摘要中之「合約資料需求清冊」資料項目010取代CDRL 010文件云云。 惟STOD文件在系爭航管自動化系統建置過程中之正式名稱為「中華民國飛航控制系統描述」（Republic of China Air Traffic Control Sys-

tem Description，簡稱ATCSD）（見本院卷十五第254、301頁）。而洛克希德公司投標文件第二冊EngineeringSection 1-TACC第3.4.3.1節規定ATCSD為洛克希德公司應提交上訴人審核之文件（見本院卷十六第43至47頁及第42頁中文簡譯，外放洛克希德公司投標文件第二冊 Engi-neering Section 1-TACC第3-132、3-141頁）。且闡明摘要「合約資料需求清冊」資料項目010規定「A briefdescription of the software documents is given in

the following paragraphs: ATC System Description(ATCSD):......Overall Computer Program Description(OCPD - Operationa.System,SCPD-Support System):.....Program Design Specifications(PDS- OperationalSystem,SPDS -Support system) The PDS is a techni-

cal requirements document to assure that the intent

of the CPFS is translated into the ATC programdesign. This is reviewed and approved prior to theinitiation of the actual programming effort. The

PDS indentified each program within eachfunctionalarea of subsystem, describes the allocation offunctions to each program, provides necessay in-terfact requirements, and identifies tables,items,

and parameters to be used or set by each program....」（見本院卷十六第49至52頁），洛克希德公司亦應提出對於航空管制系統、總體電腦程式等之描述，亦即應提交ATCSD供上訴人審查。 是不論CDRL 010經闡明摘要修正後，新舊版之差異如何，均無礙STOD文件 （即ATCSD文件）為被上訴人應自行撰寫並提交審核之文件，被上訴人主張此部分為約外要求，應非可取。

５、此部分送請中科院鑑定結果，亦認「經查民航局與洛克希德公司對於Single Thread Operational Description一詞所為翻釋，洛克希德公司解作『單機飛航操作』，而民航局釋為『航管作業流程說明』，經鑑定應以民航局的翻釋較貼切。此份文件本質為一輔助說明，用意在於描述航管作業系統流程，俾使雙方更能確認彼此對作業流程的認知，故並非為約外需求；而洛克希德公司翻譯成『單機飛航操作』較無法貼切文件的原意，容易讓人誤解為是某種新的操作需求。洛克希德公司Mr.Bob Williams在73年3月7日在Magnavox公司簡報航管作業流程時 （附件九十二號），民航局認為與實際作業相差太大，於是代為撰寫此項作業流程說明。民航局進一步提出說明，認為此文件應為洛克希德公司負責提報，並交以民航局審查。依據ATC-1000（見外放另案原證254號）設計文件（Air trafficcontrol system description，73年12月13日）第6節之6-1頁中，有顯示單機飛航操作說明。洛克希德公司雖稱需求規章並未包含『單機飛航操作說明』， 卻同意列在ATC-1000設計文件，因此本項不屬約外要求」等語（見外放鑑定報告第50至51頁）。被上訴人主張此部分為約外要求，並主張其等依闡明條款第4.1條規定調整工期，應非可取。

６、此部分既非約外要求，自無闡明條款第4.2條第1項第6款所定「任何超出民航局、美商洛克希德電子公司及／或其等所指定之要次承包商合理控制範圍外之事件所致之遲延」之情形。又被上訴人雖主張上訴人一再變更STOD之版本，致其無法完成設計云云，查民航局固於73年3月9日會議中由Mr.Peter Hou及Mr.Edward Tseng就STOD為簡報 （見本院卷十六第285頁） ，惟STOD為被上訴人應提出供審查之文件，已如前述，民航局主張其因於洛克希德相關人員於簡報時，發現該簡報與實際作業流程有極大差異，無法作為系統設計之依據，鑑於被上訴人系統設計人員無航管作業背景，為免延誤交期，民航局乃根據現行作業狀況及新系統之特性，代為撰寫此項作業流程說明，非無可取。但洛克希德公司應提供此項文件之責任，並不因民航局代為撰寫而免除，則縱上訴人嗣又因考量國際標準與管制技術之變動而提出修改之版本，亦難民航局應就此負遲延責任。被上訴人主張其得依闡明條款第4. 2條第1項第2款、第4款展延完工期限云云，亦無可取。

（）關於被上訴人主張「臺北地區管制中心最後重要設計審核遲延」部分（中科院鑑定報告第二大項第1小項）：

１、被上訴人主張民航局已同意以洛克希德公司投標文件第2冊工程第1章第3.7節之「Software Documentation（軟體說明文件）」 取代合約資料需求清冊項目010，惟民航局要求洛克希德公司就電腦程式結構項目發展規格（Com-puter Program Configuration Item Development Spe-cification，簡稱CPCI）提出超越招標文件闡明摘要（

CAA Summaryof Clarifications to the RFP Documents）「合約資料需求清冊」項目010所定之格式範圍之額外說明資料。又於73年11月20日函提出TACC最後重要設計審核進行時，擬採用之四項審核條件，均非系爭航管契約文件所規定，而屬約外要云云。惟未具體說明民航局要求何等超越「合約資料需求清冊」 項目010所定之格式、範圍額外之說明資料，及TACC最後重要設計審核之四項審核條件，如何均非系爭航管契約之範圍，且本件於 95年3月10日送鑑定後，迄至 97年12月1日被上訴人雖仍陸續就各項鑑定事項補送資料，惟就此部分則未為主張及舉證。被上訴人主張此部分為約外要求，並無足取。中科院鑑定結果亦以「洛克希德控增加非基本規章之功能需求，未見佐證資料。在SOW第5.3節明確律訂本工程案系統軟硬體，發展管理係MIL-STD-1521A規範執行PDR.、CDR.依據SOW第5.6.2節所述，工程需求規格須符合MIL-STD-490規範。因此本工程案於基本需求規章提出後，需經由初步設計、細部設計之過程，對所需之系統規格方能做完整認定。若民航局於初步、細圖部設計過程中所提出之進一步功能需、求說明，係屬合理，因此並非屬約外需求」等語，認此部分非約外要求。

２、民航局要求逐行審核洛克希德公司之設計文件，且該設計文件不僅應載明功能性需求「為何」，且應註明其「如何」執行，是否為約外需求？㈠被上訴人主張系爭航管系統CDR審查程序及進行審查之方

法均應按MIL-STD-1521附件D進行， 民航局要求逐行審核洛克希德公司之設計文件，且該設計文件不僅應載明功能性需求「為何」，且應註明其「如何」執行，為屬約外要求云云。

㈡查系爭航管自動化系統涉及飛航管制及自動化，不只極為

複雜，更攸關生命、身體、健康及財僅之安全，上訴人自應依基本需求規章所定之功能性描述，具體檢視被上訴人提出之設計文件，究竟能否及為何能夠達成如何之功能性需求，方足以確保系爭航管自動化系統能兼顧飛航管制與飛航安全之基本要求，在雙方沒有共識且民航局不了解洛克希德公司設計下，依約民航局自有權審查設計文件，至於如何審核係屬實務執行面，應非約外要求。且MIL-STD-1521A舉例指出就相關設計資訊之審核，應充分且詳細地使買受人能自使用者之觀點，評估相關設計之妥適性，並使設計人員知悉需求為何，且讓測試人員能據以準備測試（Examples of the type of design information to bereviewed are:a.....These should be presented insufficient detail to allow Procuring Activitypersonnel to judge adequacy from a human usabilitystandpoint, and design personnel to know what isrequired,and test personnel to prepare tests，見本院卷廿四第190頁），足見上訴人表示應逐行審查被上訴人之設計文件，且設計文件應註明功能性需求「為何」及其「如何」執行，無非在闡述MIL-STD-1521A相關規定之內容及實務上軟體審核程序之常規而已，應非約外要求。㈢此部分經送中科院鑑定結果，亦認「依合約民航局有權審

查設計文件，而如何審查設計文件係屬實務執行面，非屬約外要求」、「民航局要求洛克希德公司，應載明功能性需求『為何』，且應註明其『如何』執行之要求，非屬約外要求。被上訴人主張此部分為約外要求，並主張其得依闡明條款第4.1條規定調整工期，應非可取； 其以此抗辯闡明條款第4.2條第1項第3、4、6款規定之情形， 其得逐日順延完工期限，亦無足取。

３、民航局是否要求對於TCC及TACC已核准之設計文件反覆審查，致已核准之TACC及TCC設計內容無法確定，導致洛克希德公司無法進行後續硬、軟體及韌體施作？㈠被上訴人據民航局75年1月10日函主張民航局要求對於TCC

及TACC已核准之設計文件反覆審查， 致已核准之TACC及TCC設計內容無法確定，導致洛克希德公司無法進行後續硬、軟體及韌體施作云云。查民航局75年1月10日函稱：

「CAA agrees,as was discussed at the October 15Executive Review meeting, that it would be point-less to publish separate TCC ducuments that wereexact/duplicats of existing TACC documents.However,since there has not yet been a review of the de-tailed TCC requirements,it is not possible to nowidentify those documents that can serve both theTACC ans the TCC needs. CAA hopes that the sixsupport programs can be identical for both TACC

and TCC use. In addition, we would like to see SARDisk/Tape Simulation, and DYSIM be identical.How-erer, until the detailed TCC design is approved we

can not commit to those programs being identical

for both uses. Our suggestion for achieving a highlevel of commonality is that the TACC documents bewritten specifically for the TACC, without the use

of double identifiers (such as TACC(TCC) or TACC/TCC).During the preparation and review of the do-cuments, both LILT and CAA personnel should try toconsider TCC needs, but they should not be expli-citly documented. After the TCC design has stabil-ized, the previously approved TACC documents will

be re-reviewed for suitability in the TCC enviorn-ment. When possible, the TACC document will beapproved for TCC use. If changes are required, tosatisfy TCC needs, and those changes are alsoacceptable in the TACC enviornment,the documentshould be revised and approved for use in bothenviornments.(Incluede in this latter categorymight be minor special features, for one enviorn-ment or the other, that could be activated byspecial commands.) If significantly differentfeatures are required for two environments,thenseparated TCC documents and programs woule have to

be prepared.」（見本院卷十五第492頁），縱觀其內容，該函係對於10月15日會議中洛克希德公司認為如 TCC文件與TACC文件完全相同，則各別發行 TCC文件是無意義的之主張， 提出看法及對於如何達成TCC與TACC文件之高度共性之建議，被上訴人據上開函文主張民航局要求對於TAC及CTCC已核准之設計文件反覆審查，容有誤會。被上訴人復未舉證民航局就何項已核准之設計，於何時以何方式要求重新審查，其主張因民航局要求重覆審核，致民航局台北地區管制中心（TACC）之最後重要設計審核 （CDR）遲延， 抗辯其得依闡明條款第4.2條第1項第3、4、6款規定，逐日順延完工期限，委無足取。

４、民航局是否於台北區管制中心CDR進行中，提出①航路之約外要求、②空軍航管中心介面之定義變更、③狀況顯示器列表之曖昧不明及擴張、④雷達資訊關連之需求曖昧不明及矛盾、⑤完整資料欄之變更需求、⑥指定跑道／使用中跑道之約外要求、⑦國際民航組織之程序變更、⑧顯示時間間隔之曖昧不明及擴張、⑨有限資料欄之使用定義不明及矛盾、⑩飛機識別欄之約外要求、⑪單機飛航操作說明之約外要求、⑫狀況顯示器之迷你一覽表、⑬待辦工作項目對於電腦作業程式之影響、⑭台北地區管制中心計畫控制顯示器之歸航資料顯示器、⑮緊急碼之擴充等多項約外要求及基本需求規章曖昧不明及矛盾，民航局未盡及時澄清之義務，致台北區管中心CDR程序延宕？㈠查被上訴人主張之上開①民航局要求之偏好航路、②空軍

航管中心介面之定義變更、③狀況顯示器列表之曖昧不明及擴張、④雷達資訊關連之需求曖昧不明及矛盾、⑤完整資料欄之變更需求、⑥指定跑道／使用中跑道之約外要求、⑦國際民航組織之程序變更、⑧顯示時間間隔之曖昧不明及擴張、⑨有限資料欄之使用定義不明及矛盾、⑩飛機識別欄之約外要求、⑪單機飛航操作說明之約外要求等，均非約外要求，基本需求規章亦無曖昧不明及矛盾，已如前述（詳見五（）至（））。另，而⑫狀況顯示器之迷你一覽表、⑬待辦工作項目對於電腦作業程式之影響、⑭台北地區管制中心計畫控制顯示器之歸航資料顯示器、⑮緊急碼之擴充，亦非約外要求（詳見後述）。被上訴人抗辯其得依闡明條款第4.1條規定調整工期， 及得依闡明條款第4.2條第1項第6款規定順延完工期限，應非可取。

㈡而上開各該部分，民航局於洛克希德公司爭執係約外要求

時，均已及時去函或於會議中說明，詳各該部分之說明，惟因洛克希德公司不能認同，致民航局一再反覆澄清，則自難以民航局之澄清未獲洛克希德公司認同，即認民航局未盡及時澄清之義務，被上訴人主張其得依闡明條款第

4.2條第1項第6款規定順延完工期限，亦非可取。 至於被上訴人主張民航局闡明條款第4.2條第1項第3款 「未及時認可或核准資料項目」之情形，既為上訴人所否認，自應由被上訴人就此負舉證之責。而民航局有無未及時認可或核准資料項目，除自洛克希德提出文件至民航局認可及核准所費時間外，尚涉洛克希德提出之文件有無缺失、是否符合契約約定及系爭航管自動化控制系統之需求、是否完備可行、於正常情形下民航局所需之審核時期為何等項，非僅憑兩造往來信函所得判斷，被上訴人僅提出兩造往來信函主張民航局未及時認可或核准資料項目，已非可取。且洛克希德提出之文件有無缺失、是否符合契約約定及系爭航管自動化控制系統之需求、是否完備可行、於正常情形下民航局所需之審核時期為何等項，非經航空、通訊、資訊專業人員，以其專業依契約及相關往來文件研析，無法判斷，然被上訴人迄至中科院完成鑑定後，始於99年10月1日具狀爭執，應認被上訴人逾時提出，如再送請鑑定單位鑑定，必有礙訴訟之終結，本院得不再送鑑定而為審酌。被上訴人此部分主張尚屬無法證明，其主張可依闡明條款第4.2條第1項第3款規定順延完工期限，亦無可取。

（）關於被上訴人主張「終端管制中心初期設計審核遲延」部分（中科院鑑定報告第二大項第2小項）：

１、終端管制中心（TCC)軟體初期設計審核（PDR），是否因可歸責於民航局之事由遲延開始？㈠被上訴人主張終端管制中心（TCC）初期設計審核（PDR）

軟體部分預計於75年1月3日至同年3月31日進行，惟因民航局台北地區管制中心（TACC）之最後重要設計審核（CDR）遲延，且民航局提出五個TCC PDR之審查步驟，又自承人力不足，無法確保及時參與討論審查，復要求延後開始TCC之軟體PDR，俟TACC軟體PDR完成後才開始，致延宕至75年9月始開始進行云云。

㈡查被上訴人台北地區管制中心（TACC）之最後重要設計審

核（CDR） 非因可歸責於民航局之事由而遲延，已如前述。被上訴人雖提出民航局 75年7月31日函主張民航局提出五個TCC PDR之審查步驟，又自承人力不足， 無法確保及時參與討論審查，抗辯TCC之PDR是因可歸責於民航局之事由遲延開始云云，惟為民航局所否認。查洛克希德公司因TCC之PDR已因TACC之PDR遲延而延後舉行，於74年4月15日至17日之計畫檢查會議中表示「There are two key fac-tors which directly influenced the TACC scheduledelay and its costs which we did not foresee and/

or were beyond our control. These are the shortage

of skilled ATC expatriate engineers and the largernumber of these skills required to supervise thetechnolpgy transfer to the exceptionally capable

R.O.C.nationals hired by LILT......Lockheed isexpanding its ATC staff in Plainfield (includingconsulting firms)which will be available as re-uired to support the LILT contract activities.」，自承其人力極為短缺，超乎預期，將TCC系統之軟體設計工作改由美國平原市之洛克希德電子公司進行設計（見本院卷九第166頁） ，被上訴人亦自承其於在美國組成第二組工作隊（見本院卷十五第529頁） ，故TCC之PDR會議亦將於美國而非台灣召開。 又查民航局75年7月31日函末段固載「I amconcerned about our abilities to package

the work effrots in a useful manner which willassure that the conduct and attend presentations;

to prepre, review and comment on documentation,

and to discuss, evaluate and assimilate the com-ments」，惟該函文主旨為「TCC PDR and Related Do-cumentation Reviews」，其內記載「..Recognizing thefact that Lockheed has elected to do the TCC de-sign in Plainfield, N.J. rather than here in yourTaipei facility, the CAA has agreed in principlewith this decision in order to minimize the com-petition for your limited resources here in Taipeiwhich could have adversely affected the ongoingTACC design effort and schedule. We are willing tohave a limited number of our staff and MITRE sup-port personnel travel to Plainfield for the con-duct of part of the TCC PDR provided that a tho-rough documentation review can be accomplished by

our staff prior to the conduct of the PDR and that

the sequiencing of PDR topics be undertaken in amanner which will permit our staff to be organized

in a meaningful way which will eliminate exces-sively lost visit to Plainfield of more than threeweeks duration by any on of my staff member.」表示因洛克希德公司將TCC系統之軟體設計工作改於美國平原市進行，民航局鑑於洛克希德公司於台灣有限之資源已影響TACC設計時程，原則上同意配合指派部分民航局人員及邁特公司支援人員到平原市審核部分TCC之PDR，而「Toaccomplish this, we recommend that:⑴the TCC docu-mentation be thoroughly reviewed by the Lockheedstaff both here in Taipei and in PLainfield prior

to sending it to my office;⑵as the initial phase

of PDR Lockheed should presend a TCC top-leveldesign here in Taipei; ⑶apresentation on eachinvividula design document should be made in Tai-

pei soon (within 2weeks)after the respective docu-ment delivery, (The presentation should review

the contents of the document, identif any issuesassociated with it and provide a substantive re-view of any areas of change (additions, deletionsand/or modificatins) from the companion TACC do-cument;⑷the detiiled documentation review will beconducted by my staff and comments wiil be for-warded to Lockheed within the allocated contrac-tuarl time period;⑸The PDR will resume in Plain-field beginning with the presentation of areasfound to be missing or unacceptable in the initial

top level design presentation, the presentation of

any areas found to be missing or unacceptable in

the individual design document presentation to-gether with any requested analyses or clarifica-tions resulting from the earlier design document-ation presentation;and a reveiw and discussions of

the CAA staff's comments.」，故民航局所提五個TCCPDR之審查步驟，係為因應洛克希德公司將TCC系統之軟體設計工作改於美國平原市進行，為期TCC之PDR能順利有效進行所為建議。上訴人主張洛克希德為彌補其自身人力不足且欠缺航管專業之缺失，決定於美國進行TCC系統之PDR，因TCC PDR審核會議將於美國而非台灣召開， 民航局需派員赴美參與審核會議，額外衍生大量之經費負擔、時間及人力調度等問題，故而於75年7月31日去函說明 「在認知被上訴人未選擇台北，而以選擇美國平原市進行TCC 系統之PDR後， ……我方顧慮者係有無足夠人力，以有效方式執行並出席文件提報、準備、審核與評論，及討論、評價與吸收相關之評論」，並非自承人力不足，應為可取。被上訴人主張民航局75年7月31日提出五個TCC PDR之審查步驟，又自承人力不足，無法確保及時參與討論審查，抗辯TCC之PDR是因可歸責於民航局之事由遲延開始云云，應無可取。

㈢另被上訴人雖主張民航局於75年8月29日函要求洛克希德

公司應俟民航局核准TACC CDR軟體設計文件後，始能提出TCC PDR相關軟體設計文件，導致TCC軟體PDR遲延云云。查民航局75年8月29日固函稱「2.Lochheed should notdeliver documents for the TCC which do not include

all the changes made to the companion TACC docu-ments, unless piror agreement is given to exclude

or defer any idnetified item. In particular, Lock-heed should not deliver documents for the TCCpiror to the approval by CAA of the companion TACCdocuments」（見本院卷十五第559頁），惟系爭契約明定系爭航管自動化系統之發展期程， 應俟TACC系統通過CDR審核後，再進行TCC系統之PDR程序（見外放原審原證卷第一冊原證四），洛克希德公司投標文件第二冊「Engineering」Section 2-TCC第1-19頁亦載「The TCC OperationlProgram modifications are in most cases directcopies of TACC Operational Program which are deve-loped prior to the TCC PDR （TCC操作程式之修正，多數為在TCC之PDR前即已建置完成之TACC操作程式之直接複製」（見本院卷十六第295頁），而依SOW第5.3.1與5.3.3節規定，民航局於PDR或CDR階段，對於洛克希德公司提交之TACC與TCC之設計文件，有核准之權限 （見本院卷十六第296至298頁），民航局主張TCC系統PDR階段之開啟，以TACC系統CDR結束或經民航局核准相關CRD文件為前提，其於 75年8月29日致洛克希德公司之函，不過在闡述系爭契約關於航管自動化系統之建置流程，非提出約外要求，亦非本件被上訴人遲延之原因，尚非無據。被上訴人主張民航局於 75年8月29日函要求洛克希德公司應俟民航局核准TACC CDR軟體設計文件後， 始能提出TCC PDR相關軟體設計文件，導致TCC軟體PDR遲延云云，應非可取。被上訴人雖又主張洛克希德公司75年9月1日函請民航局儘速開始進行TCC軟體之PDR，惟民航局置之不理，致TCC軟體PDR遲延云云，惟TCC系統之PDR經洛克希德公司於75年10月14日函請民航局參加後，隨即展開（見本院卷十六第55頁），被上訴人主張民航局置之不理，致TCC軟體PDR遲延，亦無可取。

２、終端管制中心（TCC）軟體初期設計審核（PDR），是否因民航局於TCC之PDR進行中提出多項約外要求而遲延？㈠被上訴人主張民航局TCC PDR進行中， 提出待辦事項第52

項至57項、第62項等多項約外要求，且未及時澄清或承認該等要求為約外要求，以變更指令指示洛克希德公司變更工程，俾洛克希德公司得及時據以執行系爭航管工程，致

TCC PDR程序延宕至1987年3月20日始完成云云，惟為被上訴人所否認。查：

㈠被上訴人主張民航局提出待辦事項第52項「單機飛航操作說明」部分，並非約外要求，業經敘明於上五（）。

㈡被上訴人主張民航局提出待辦事項第53項「於TACC系統之

歸航資訊顯示器中新增四個警報區域及一個要求區域」之約外要求涉及並包含於中科院鑑定項目第四大項第3小項「台北地區管制中心計畫控制顯示器之歸航資訊顯示器」（見本院卷十五第532頁） ，惟此部分經中科院鑑定結果，認非屬約外要求（詳見後述，及外放鑑定報告第69至70頁）。

㈢就被上訴人主張民航局提出待辦事項第54項「在TACC系統

新增交叉資訊區域功能」及第55項 「於TCC飛航資料輸入格式提出七個不同之TCC飛航資料輸入格式」 之約外需求部分，被上訴人主張此二部分涉及並包含於中科院鑑定項目第四大項第2小項 「待辦之工作項目對電腦作業程式之影響」（見本院卷十五第533頁） ，惟被上訴人於送請中科院鑑定時，就此部分僅乏稱「民航局依合約中『中華民國應提供之設備及服務一覽表』（GFE）中第18項，應提供顯示器格式資料，並在民國73年初期設計審核會議中列入待辦工作項目第36.51.52項，以配合洛克希德之電腦程式設計，民航局卻要求洛克希德應提供，易言之，民航局將本應由其提供GFE之顯示器格式資料，強要求洛克希德提供」云云（見外放對「航空管制自動化系統」鑑定事項之說明第83頁），並未就上開第54項及55項為具體之主張，亦未提出相關佐證資料。 且本件於95年3月10日送鑑定後，迄至 97年12月1日被上訴人雖仍陸續就各項鑑定事項補送資料，惟就此部分則未為主張及舉證。中科院鑑定報告亦稱「洛克希德公司聲稱民航局強要其提出顯示格式資料，卻無提出相關佐證顯示民航局有強要之作為」，並因此認「洛克希德公司『待辦之工作項目對電腦作業程式之影響』之控訴，應屬不當」等語（見外放鑑定報告第68頁）。而此部分是否屬於約外要求，及有無闡明條款第4.2條第1項各項所定情形，非經航空、通訊、資訊專業人員，以其專業依契約及相關往來文件研析，無法判斷，被上訴人迄至中科院完成鑑定後，始於99年10月11日具狀主張此部分為約外要求，應認已逾時提出有礙訴訟之終結，且被上訴人亦未舉證具體說明各該待辦事項之內容為何、何以該部分為約外需求，其主張此部分為約外要求，尚屬無法證明而無可取。

㈣被上訴人就民航局待辦事項第56項「塔台駕駛飛航資料顯

示資訊區域」增加天氣資料、雜項變示顯示區域，及使用中跑道等約外需求及變更第57項「塔台飛航資料顯示器」分割螢幕之規格為2欄，每1欄之每行得容納40字元之約外需求部分，主張此二部分涉及並包含於成大航太所鑑定項目第四大項第1小項「塔台飛航資料顯示器之分割螢幕」（見本院卷十五第534、535頁），惟成大航太所鑑定結果，就兩造爭執之「塔台飛航資料顯示器之分割螢幕」部分，已認不屬於約外要求（見外放補充鑑定報告第72頁，另詳後述），被上訴人主張此部分為約外要求，亦無可取。㈤被上訴人主張民航局於75年12月19日TCC軟體PDR會議中被

指派回應待辦事項第63項有關 「TCC重新分區」之事項，民航局於 76年4月20日提出洛克希德應使每個控制者在重新分區時，手動接受位置上之切換之約外要求云云，惟為上訴人所否認。惟此部分並不在中科院及成大航太所鑑定之範圍，而此部分是否屬於約外要求，及有無闡明條款第

4.2條第1項各項所定情形，非經航空、通訊、資訊專業人員，以其專業依契約及相關往來文件研析，無法判斷，被上訴人於中科院出具鑑定報告後，始於99年10月11日具狀主張此部分為約外要求，應認已逾時提出有礙訴訟之終結，且被上訴人亦未舉證具體說明各該待辦事項之內容為何、何以該部分為約外需求，其此部分主張，即屬無法證明而無可取，其主張此部分為約外要求，亦無可取。

㈥上開部分既均非約外要求，被上訴人主張可依闡明條款第

4.1條調整完工期限，自無可取。 又此部分既非約外要求，民航局自無發出變更指令之必要，亦難以洛克希德公司認係約外要求而不認同民航局之澄清，即認民航局未及時澄清，是自無闡明條款第4.2條第1項第3款 「未及時認可或核准資料項目」、第4款 「民航局未能依約及時完成於本契約下之任何其他義務」及第6款 「任何超出民航局、美商洛克希德電子公司及／或其等所指定之要次承包商合理控制範圍外之事件所致之遲延」所定之情形，被上訴人就此部分其得依闡明條款第4.1條規定調整完工期限， 及依闡明條款第4.2條第1項第3、4、6項規定順延完工期限，並無足取。

（）關於被上訴人主張終端管制中心最後重要設計審核遲延」部分（中科院鑑定報告第二大項第3小項）：

被上訴人主張終端管制中心（TCC）最後重要設計審核（CDR）軟體部分預計於1986年6月1日至同年7月31日進行，惟因 ①民航局延誤TACC之CDR及TCC軟體PDR，②民航局在TCC軟體PDR階段， 所提關於TCC軟體之約外要求尚未解決，在TCC軟體CDR階段又提出新的約外要求，③民航局違反MIL-STD-1521A所定審查方式， ④民航局拒絕履行從速審查洛克希德所為TCC軟體CDR設計文件之定作人協力義務，⑤民航局拒絕繼續TCC軟體CDR審查程序，致TCC軟體CDR迄77年6月25日民航局終止契約時尚未完成云云，惟為上訴人所否認。茲就上開被上訴人之主張分述如下：

１、TCC軟體CDR是否因可歸責於民航局之事由致遲延開始？被上訴人主張依契約航管契約第四次修正，TCC軟體PDR部分預計於75年3月31日完成 ，TCC軟體CDR預定於75年6月1日開始，但原定於74年12月27日完成之TACC CDR，因可歸責於民航局之事由延至75年9月始完成， 致TCC軟體PDR時程延宕，又因可歸責於民航局之事由致原定於 75年3月31日完成之TCC軟體PDR延至 76年3月始完成， 導致TCC軟體CDR亦延至76年5月始開始進行云云。 惟查TACC之CDR非因可歸責於民航局之事由致遲延，且TCC之軟體PDR亦非因可歸責於民航局之事由而遲延開始及結束，已如前述（見上五（）、（）），則被上訴人主張TCC軟體CDR係因可歸責於民航局之由致遲延開始，應無可取。

２、民航局於TCC軟體PDR及CDR階段，有無提出新的約外要求？㈠被上訴人主張民航局於TCC軟體PDR階段，提出待辦事項第

52項至第57項之約外要求，且未及時澄清該等逾越之處並依闡明條款第4.1條、第4.3條規定，以變更指令指示洛克希德公司變更工程，強要求洛克希德公司施作， 延誤TCC軟體CDR時程云云， 惟待辦事項第52項至第57項並非約外要求，已如前述（詳見五（）２所述），則被上訴人主張上訴人提出此部分約外要求，致延誤TCC軟體CDR之時程，應非可取。

㈡又被上訴人主張民航局於TCC軟體CDR階段，提出關於「Ｅ

欄顯示資料之優先次序」之約外要求，延誤TCC軟體CDR時程云云。「Ｅ欄顯示資料之優先次序」並非約外要求，已如前述（詳見五（）７所述），被上訴人主張上訴人提出此部分約外要求，致延誤TCC軟體CDR之時程，亦非可取。

３、民航局是否違反MIL-STD-1521A所定審查方式？被上訴人主張民航局違反MIL-STD-1521A所定之審查方法，要求洛克希德公司關於功能性需求「為何（What）」應說明「如何（How）」執行之資訊，且要求逐行審查TCC系統設計文件之約外要求，嚴重延宕TCC之CDR時程云云。惟查民航局要求逐行審核洛克希德公司之設計文件，且該設計文件不僅應載明功能性需求「為何」，且應註明其「如何」執行，未違反MIL-STD-1521A所定之審查方法， 亦非約外需求，業經敘明如前（詳見五（）２），被上訴人主張民航局提出此部分約外要求，致延誤TCC軟體CDR之時程，並無可取。

４、民航局是否拒絕履行從速審查洛克希德所為TCC軟體CDR設計文件之定作人協力義務？被上訴人主張洛克希德於 76年12月4日提出⑴民航局不應提出具體建議，⑵民航局應事先訂立每日審查頁數之目標，及⑶民航局人員應於晚上或假日加班審查文件等具體建議，函請民航局加速進行TCC CDR， 民航局終於76年12月21日函文承認其提出之要求為約外要求云云。查民航局76年12月21日「Subject:TCC-CDR」函稱：「The CAA hasconsidered your reference letter with great inter-

est.We share your concern about the duration of

the CDR and your disire to conclued it at an earlydate. However, we believe that there are otherfactors,which have contributed significantly to

the duration of the reviewing period, that were

not mentioned in your letter. Some of these fac-tors are addressed in the attachment to this let-

ter.Your letter requests CAA assistance in expe-diting the remaining CDR activities so as toeduce the time required to complete the CDR.We, ofcourse, will do whatever we can to facilitate thereview. However, the purpose of the review should

not be circumevented - to evalute the completeness

and adequacy of the design.It is necessary that

the functional design be completed as quickly aspossible....」（見本院卷十五第701頁） ，細繹其內容，並未見民航局有提出約外要求之自承，並對洛克希德公司提出加速進行TCC CRD之要求 ，採取審慎之態度，表示為評估洛克希德公司所提設計文件之完備性與妥適性，相關審查並無從迴避或取巧；並於該函附件表示：「Thepurpose of the TCC CDR is to evaluate the complet-ness and adequacy of the TCC design, and to formu-late connections of additionsto that design ifshort-comings are identified. One major aspect ofthat evaluation is to ensure that the designapporpriately responds to the system specifica-tions. Therefore, to successfully complete thedocument evaluation it is necessary that: ◇Thecontractor understand the system requirements; and◇the customer understand the system design.....Inboth the TACC and TCC reviews,the CAA has foundthat:◇The contractor personnel at times do notunderstand Air Traffic Control well enough toproperly interpret the system, requirements -which necessitates CAA personnel explaining ATCporcedures and their relationship to the require-ment; and ◇The CAA personnel at times do notunderstand the system design, due to the inade-quate and incomplete nature of the sign documents- which necessitates Lockheed personnel explaining

the design and tis relationship to the require-ments. Both of these problems result in extending

the time required for a review.」 表示順利進行TCCCDR審查，須出賣人瞭解系爭系統之需求及買受人理解系爭系統之設計，惟在審查洛克希德公司提交之TACC及TCC設計文件時，發現洛克希德公司人員不甚瞭解飛航管制，致未能適切理解系統需求，而須民航局人員解釋飛航管制程序及該程序與相關需對之對應關係，且洛克希德公司提交之設計文件不完備及不充分，致民航局人員有時不能理解系爭系統之設計，上二原因導致相關審查需時延長（見本院卷十五第702頁），並稱「Unfortunately theexperiences of the past four years have caused the

CAA have limited confidence in Lockheed's alility

to independently create a satisfactory design.Ourexperience has shown that detailed review of allLockheed dsigns is necessary in order to ensurethat they are complete and adequate.Therefore,in

any balancing of review expedition against reviewcomprehensiveness, the CAA will favor the compre-hensiver review.The CAA has also directed itspersonnel to refrain from extending the scope of

the system by adding detailed requirements which

are not implied by the system specifications.(Implication is needed, since it is not possible

for all detalied requirements to be explicitlystated in the system specifications.)Unfortunately,the line between what is, and what is not,implied

by the specifications is not always obvious. Insuch circumstances, ti is common for the contrac-

tor to claim additonal scopes, and for the custo-

mer to disagree....」 ，表示鑑於過知四年的經驗，民航局對於洛克希德公司獨立完成設計之專業能力並無信心，為確保相關設計文件之完備與妥適，民航局將對洛克希德公司提交之文件進行全面廣泛之審查；而為使洛克希德公司了解系爭系統之設計流程，民航局將克制所屬人員避免提出無法以推理方式自規格書相關描述中導出之系統需求（但以推理方式導出系統功能，仍屬必要，因為難以在規格書中鉅細靡遺明定所有系統需求），不幸的是，是或不是得以推理方式導出之功能之界線，不是都很明顯，致雙方看法不同（見本院卷十五第703頁），又稱「Theletter makes some specified suggestions, including：◇ CAA to refrain from adding out-of-scope re-quirements.As is notedabove, the CAA has directedthat this not be done, and is unaware of itshaving been done......◇Continue discussions into

the night or weekend is the page count quota has

not beed achieved. This is not feasible.Extendingmeetings into the evening would not be efficient;ther is a limit on the porductive discussion that

can be held in one day. Extending meetings into

the weekends would not be acceptable; many SPOmember have othe CAA responsibilities, which must

be satisfied on the weekends; at previouslyscheluled times.....」，表示將約束所屬人員不提出所謂約外要求，且民航局亦不認為曾提出所謂之約外需求，對於洛克希德公司關於民航局人員應於晚上或假日加班審查文件之建議，亦詳細說明其不可行之原因（見本院卷十五第704頁） ，是綜觀民航局76年12月11日函文，並未承認其提出之要求為約外要求，亦無無正當理由拒絕履行從速審查TCC軟體CDR設計文件之協力義務之情形，被上訴人主張民航局自承提出約外要求，又拒絕履行從速審查洛克希德所為TCC軟體CDR設計文件之定作人協力義務，致延誤TCC軟體CDR之時程，並無可取。

５、民航局是否拒絕繼續TCC軟體CDR審查程序，致TCC軟體CDR無法完成？被上訴人主張民航局人員於77年3月7日致電洛克希德公司人員，通知中止TCC軟體CDR之審查程序，惟為上訴人所否認，查洛克希德公司固於77年3月31日函民航局稱「This

is a request to resume the subject meetings whichwere cancelled by the CAA in the reference tele-cope.The stated reason for not recovening the TCC

CDR was that the CAA was:too busy on other matters.Lockheed has received no further advice from the

CAA concerning the status of the TCC CDR. Lockheedis, and has been, prepared to continue immediately」，嗣又於77年4月19日函民航局稱「....Lockheed sub-mitted its Program Completion Plan (ATC-PCP-001)on

15 January,1988(three months ago) and as of thisdate Lockheed has not received any indication fromCTC/CAA if this Plan is satisfactory.....TCC Soft-ware Criticla Design Review(CDR) ─ All TCC Soft-ware CDR meetings were suspended by the CAA on 7March 1988 via a telephone call from Mr.Tseng to

Mr.M.Wedge.The drawn-out nature of these meetings

had affected Lockheed performance prior to yourReference (I) letter, and this further delay willcause additional cost as well as schedule exten-sions.」，有各該信函在卷可稽 （見本院卷十五第708頁）。 惟此均係於民航局76年12月1日主張洛克希德公司履行契約遲延限期洛克希德公司提出補救計畫之後，縱認屬實，於民航局於 76年12月1日發函時洛克希德公司已否履行契約遲延之判斷並無影響。

６、關於被上訴人主張終端管制中心最後重要設計審核遲延部分經中科院鑑定結果，亦以「依據SOW第5.6.2節所述，工程需求規格須符合MIL-STD-490規範。 所謂基本需求規章，應屬MIL-STD-490規範中所定義的A規(System/ segmentspecification)，其所作用為描述系統一般功能，該功能細部必須再進一步加以定義方能明確。故規劃賣方（得標廠商）需依據本工程案PDR、CDR的審查流程與規範，對於細部功能必須再進一步於PDR、CDR階段再加以定義方能明確，俾使買方可藉由各階段設計審查之機會進一步檢視賣方之履約能力是否足以完成契約。 民航局於76年3月20日函覆洛克希德公司，依雙方之協議，TCC之CDR審查之條件有四項，其中(1)所有PDR所產生的工作項目必須定案解決。 (2)在審查會中所確認”matrix”項目之需求資料提出後。(3)各項CDR所需相關之正式文件須先送交民航局。

(4)TCC軟體設計中有關ATC-914不確定因素之影響解決後。綜觀洛克希德公司TCC之PDR產生之工作項目（Actionltems）共73項，遲至76年5月尚未全數完成解決。另洛克希德公司遲至76年11月才將上述資料遞交給民航局；上述二因素直接導致延誤TCC之CDR時程及作業」，認「依據本工程案PDR、CDR的審查流程與規範，買方可藉由各階段設計審查之機會，進一步檢視賣方之履約能力是否足以完成契約。綜上所述，本項鑑定結果並無洛克希德所稱之「終端管制中心最後重要設計審核延遲」之情形，而是洛克希德公司須負大部分延誤責任」等語（見外放鑑定報告第56至57頁）

７、綜上，民航局既無延誤TACC之CDR及TCC軟體PDR、未於TCC軟體PDR及CDR階段提出約外要求、 未違反MIL-STD-1521A所定審查方式、未拒絕履行從速審查洛克希德所為TCC軟體CDR設計文件之定作人協力義務、未拒絕繼續TCC軟體CDR審查程序，則被上訴人主張其可依闡明條款第4.1條規定調整完工期限及依闡明條款第4.2條第1項第3、4、6項規定順延完工期限，即無可採。

（）關於被上訴人主張「民航局就資訊通訊網路設計文件之審核遲延」部分（中科院鑑定報告第二大項第4小項）：

１、民航局要求洛克希德公司評估「微波頻道資料傳輸速率到達19200位元/秒之可能性」，及進行「微波頻道品質測試」，是否為約外要求？㈠上訴人主張依系爭航管契約74年8月8日第四次修正之「中

華民國政府應提供之設備及服務（List of ROC Fur-nished Equipment Services，下稱GFE）第14條ｄ項規定，民航局應負責評估及測試通訊連結之品質。又TACC規格書規定「發據傳輸速率，最小為2400位元／秒，最大不得超過9600位元／秒」，惟民航局於75年1月9日函要求洛克希德公司評估「微波頻道資料傳輸速率到達19200位元/秒之可能性」，洛克希德公司於 75年3月19日函覆，若民航局能提供四個微波頻道，洛克希德公司可考慮接受改使用微波頻道，以符民航局關於19200位元/秒傳輸率之要求。

民航局於75年5月5日表示可以提供六個微波頻道，洛克希德公司乃於 75年5月15日函覆同意在松山塔台及臺北終端管制中心間之通訊連結使用微波頻道，並於 75年5月13日提出工程變更案，民航局於 75年5月31日對於工程變更案表示疑慮。 洛克希德公司於75年8月14日提出「合約資料需求清冊」 （CDRL）資料項目009項中有關資訊通訊網路設備之TCC-917設計文件供民航局審核，並於75年8月20日函中表示將於系統測試時，測試民航局提供之連結頻道，及要求民航局依上述需求之變更，進行相應之規格變更。詎民航局未依GFE規定自行測試通訊連結之品質，反而於75年9月16日函要求洛克希德公司逕進行測試云云。㈡查民航局75年1月9日函中雖表示「Some of our

engineers suggest that the microwave channel beimplemented on the digital communication betweenSung Shan Tower and Taipei TCC. The frequencyresponse and characteristic of each channel willcomply with the CCITT standard. The frequencyrange is from 300 Hz to 3400 Hz.Please evaluate

the possibility of increasing the data speed up to

19.2KBPS」請洛克希德公司評估「微波頻道資料傳輸速率到達19200位元/秒之可能性」（見本院卷十五第759頁），惟依民航局75年5月31日函稱「In order to consider

the Lockheed proposal to increase the data rateabove 9600 bps, the CAA will need either thecomplete specification of the required data inter-channel requirements which will essure successfulface operation or a proposal for the removal of

the data channels between the towers and the asso-ciated TCCs as GFE requirements （為了考慮洛克希德公司建議增加松山塔台與TCC系統間每秒9600位元之數據傳輸速率，民航局需要……）」（見外放上訴人所提鑑定說明資料附件121），且民航局75年10月1日函並表示「

The data rate for the interface between the CKS

TCC and the Sung Shan Tower is proposed as 19.2KBS. The CAA can not approve the data rate on thisinterface until the testing of the availablemicrowave data channels is completed and that ananalysis of the test results reveals that the

19.2KBS rate can be sustained while main taining

an acceptable errar rate on the channels（松山塔台與TCC系統間數據傳輸速率，被建議為每秒19200位元，但民航局將無法同意，除非微波頻道之測試已完成，且測試結果分析報告顯示傳輸速度可以維持19200/秒，以及錯誤率可接受）」 （見外放上訴人所提鑑定說明資料附件125），參諸洛克希德公司於74年10月28日TCC硬體PDR會議中表示「Mr.M.Arnold,LILT stated that the exeternalinterfaces shown on pate 8-5and 8-6 for the TCFDD

and TCDD showm data speeds at 9600 PBS.This maychange depending upon the information obtainedfrom the fact finding team identified in 2 above.」（見外放上訴人所提鑑定說明資料附件158），及民航局 75年5月5日就Reference：LILT/JBG/2404 dated 19March 1986，及2.LD-0000000 dated 9 January 1986所為函文載「In response to your letter, reference 1,please be advised that the CAA can provided up to

6 microwave voice channels between Sung Shan Tower

and Taipei TCC for TCC RDP and FDP data communica-tions....Please evaluate the possiblity of in-creassing the data speed up to 19.2KB proposed inreference 1.....」（見外放上訴人所提鑑定說明資料附件120） ，上訴人主張洛克希德公司在TCC系統之硬體PDR會議表示，TCC系統與塔台間之數據傳輸速率需達19.2KB（相當於19200位元/秒），民航局始出於協助之立場，於上開75年1月9日函說明洛克希德公司可先試用松山塔台與中正終端管制中心間已經設置之微波通送，評估能否滿足被上訴人所為傳輸速率無應增加至19.2KB之要求，尚非無據。被上訴人抗辯數據傳輸速率增加為19.2KB為上訴人所提約外要求，應無可取。

㈢又上訴人於被上訴人表示如果可以提供四個微波頻道，即

認為可行後，於75年5月5日函請洛克希德公司評估相關之可行性，並請洛克希德公司確定該六個微波頻道之使用，不會干擾到微波系統其他頻道之使用（見外放上訴人所提鑑定說明資料附件120） ，惟洛克希德公司遲未評估，經民航局於75年10月1日表示「The CAA can not approve

the data rate on this interface until the testing

of the available microwave data channels is com-pleted and that an analysis of the test resultsreveals that the 19.2KBS rate can be sustainedwhile main taining an acceptable errar rate on thechannels（除非微波頻道之測試已完成，且測試結果分析報告顯示傳輸速度可以維持19200/秒，以及錯誤率可接受，否則民航局不會同意該資料傳輸速度）」後（本院卷十五第789頁，外放上訴人所提鑑定說明資料附件125），洛克希德公司始於 75年11月4日進行測試（見本院卷十五第792頁） 。查洛克希德公司既不採用TACC規格書原約定之傳輸數率及通信電路，改採另外方案，自應自行測試該方案之可行性，洛克希德公司遲不測試，民航局於 75年9月16日函要求洛克希德公司進行測試，乃係因應洛克希德公司將數據傳輸速率提升至每秒19200位元之建議， 被上訴人指民航局要洛克希德公司評估「微波頻道資料傳輸速率到達19200位元/秒之可能性」，及進行「微波頻道品質測試」，為屬約外要求，應非可取。

㈣此部分經中科院鑑定結果，亦認「在初期設計審查會中，

洛克希德公司表示，依據航跡目標及情資顯示資料量，塔台與終端系統間之數據傳輸速率須建1.92 K位元／秒，洛克希德已違反系統規格在先。基於協助立場，民航局建議試用已有之微波通信系統，並請洛克希德公司先行測試是否符合所需，並請洛克希德公司提出分析報告。……本工程案洛克希德公司採用買方所提供之電路，而改採另外方案，洛克希德公司應該自行測試方案是否可行」（見外放鑑定報告第57頁）。此部分既非民航局之約外要求，則被上訴人主張其得依闡明條款第4.1條規定調整工期， 應非可取。又洛克希德公司在TCC系統之硬體PDR會議表示，TCC系統與塔台間之數據傳輸速率需達19.2KB，已違反TACC規格書之約定在先，而依GFE之約定， 數據傳輸線路應由民航局提供，民航局為確保傳輸品質，乃於75年1月9日建議其測試已存在之微波通道，用以評估將數據傳輸速率提高至19,200位元/秒之可行性（見本院卷十五第759頁），洛克希德公司遂於 75年3月19日發函要求民航局提供可供測試之微波通道數量（見本院卷十五第761頁） ，民航局即於75年5月5日函覆可提供六條微波通道供其測試（見本院卷十五第763頁） ，乃洛克希德公司遲未進行測試，經民航局於75年8月5日、9月16日、10月1月一再函請洛克希德公司測試（見外放上訴人所提鑑定說明資料附件122、

124、125），洛克希德公司始於75年11月4日進行測試（見本院卷十五第792頁） ，難認民航局有未提供GFE 設備，或遲延完成審核之情形，被上訴人主張此部分有闡明條款第4.2條第1項第2、3、4款情形， 其得依逐日順延完工時程，並無可取。又民航局既係配合洛克希德公司之建議，請洛克希德公司評估「微波頻道資料傳輸速率到達19200位元/秒之可能性」，及進行「微波頻道品質測試」，亦難認此部分超出洛克希德公司合理控制範圍，被上訴人抗辯其得依闡明條款第4.2條第1項第6款規定逐日順延完工期限，亦無可取。

２、民航局要求 「TCC-917設計文件需與尚未採購之馬公終端雷達系統相容」，是否為約外要求？㈠被上訴人主張民航局於76年1月6日要求洛克希德公司修改

TCC-917設計文件， 使系爭航管系統能與其未來即將採購之馬公終端雷達系統相同，但系爭航管契約之基本需求規章並無約定資料通訊網路設備之設計文件需與民航局尚未採購之終端雷達系統相容，且經雙方澄清、討論後，民航局嗣於 76年8月31日撤回上開要求，足見上開要求確屬約外要求云云。

㈡查TCC規格書第3.7.6節「Radar Target Extractor Func-

tional Area」約定「The contractor shall provideradar target extractor equipment compatible withexisting and planned CAA SRR systems」（見本院卷十六第68頁，外放TCC規格書第3-386頁），已規定TCC系統之雷達目標擷取器，應符合民航局現有及規劃中之雷達，而馬公雷達為當時規劃中之雷達，則上訴人主張民航局去函說明資訊通訊網路設計文件應能與馬公雷達相容，不過重申TCC規格書第3.7.6節之規定，並非提出約外要求，應可信取。

㈢又民航局雖嗣於76年8月31日撤回「TCC-917設計文件需與

尚未採購之馬公終端雷達系統相容」 之要求， 惟依規定TCC系統雷達目標擷取器既應符合民航局現有及規劃中之雷達，則民航局縱撤回 「TCC-917設計文件需與尚未採購之馬公終端雷達系統相容」之要求，亦難認此項要求為約外要求。被上訴人抗辯此部分為約外要求，應為可取。

㈣民航局「TCC-917設計文件需與尚未採購之馬公終端雷達

系統相容」之要求，既非約外要求，則被上訴人主張其得依闡明條款第4.1條規定調整工期，應非可取。 又民航局嗣雖撤回此項要求，惟此係因洛克希德公司一再爭執，陳稱需重新設計、修改設計基準文件及相關文件，將會導致大幅增加系爭航管工程成本及工期，民航局因恐影響系爭航管系統之進度而撤回，並同意此部分洛克希德公司可不依TCC規格書第3.7.6節規定履行，並於洛克希德公司76年11月4日完成微波頻道測試後，即於76年11月5日核准洛克希德公司之TCC-917設計文件（見本院卷十五第816頁），亦難認有闡明條款第4.2條第1項第2、3、4、6款規定之情形。此部經中科院鑑定結果，亦認「招標文件中已標明雷達目標擷取器（Radar Target Extractor）須符合民航局現有與規劃中之雷達，而馬公雷達屬規劃中之雷達，因上述通信傳輸數據變更，故民航局主張洛克希德公司應考量其設計與馬公雷達之銜接，係為合理。故洛克希德公司認定民航局藉此之故遲延核准簽署文件，並非正確」（見外放鑑定報告第58頁），被上訴人主張其得依闡明條款第

4.2 條第1項第2、3、4、6款規定，逐日順延完工期限，並無足取。

（）關於被上訴人主張「系統測試計畫及程序審查遲延」部分（中科院鑑定報告第二大項第5小項）：

１、民航局有無延誤台北區管中心（TACC）之最後重要設計審核（CDR），導致洛克希德公司應備置之TACC系統測試文件之時程受影響？㈠被上訴人主張招標文件闡明摘要中合約需求清冊（CDRL）

第021項，TACC系統之「系統整合及執行測試計畫文件」應於TACC系統驗前240天提出，TACC系統之 「系統整合及執行測試程序文件」 應於TACC系統驗前120天提出，惟因民航局延誤TACC CDR，導致洛克希德公司應備置之TACC系統測試文件之時程受影響云云。 惟民航局於TACC之CDR進行中並無提出約外要求， 亦無闡明條款第4.2條第1項第3、4、6款之事由致延誤TACC之CDR 時程，已如前述（詳見五（）） ，民航局既未延誤TACC之CDR，則被上訴人主張其應備置TACC系統測試文件之時程因民航局延誤TACC之CDR而受影響， 並主張民航局應就TACC系統測試文件之審核遲延負責，並無足取。

２、民航局於TACC系統測試文件審查中，要求TACC系統測試文件（CDRL 021）應依「CDRL 020測試計畫之格式及內容標準」撰寫，是否為約外要求？㈠被上訴人主張洛克希德公司於76年4月17日提出CDRL 021

文件之一之TACC系統測試計畫文件，民航局於 76年7月15日始回覆其審查意見。嗣洛克希德公司於76年10月27日提出同為CDRL 021文件之一之TACC系統測試程序文件，民航局於77年1月8日回覆其審查意見，並稱洛克希德公司於76年4月17日提出之TACC系統測試計畫文件不符合「CDRL020測試計畫之格式及內容標準（Formate and contentGuide for the Preparation of CDRL 020）」之要件，要求洛克希德公司依該CDRL 020測試計畫之格式及內容標準修改TACC系統測試計畫文件，並稱TACC系統測試程序文件係依據TACC系統測試計畫文件備置，故其對TACC系統測試程序文件之審查意見與對TACC系統測試計畫文件之意見相同，要求洛克希德公司應依CDRL 020測試計畫之格式及內容標準，修改屬於CRDL 021之TACC系統測試程序文件。

但TACC系統測試文件係屬CDRL 021資料項目中之文件，而民航局要求適用之CDRL 020測試計畫之格式及內容標準所規範者為CDRL 020資料項目中之文件，二者不同，民航局之要求，為屬約外要求云云。

㈡惟被上訴人於送請中科院鑑定時，就「系統測試計畫及程

序審查之遲延」，僅泛稱「此計畫及程式係為進行系統驗收測試而設，其必須俟系統之基本設計完成後而可擬具，惟由於民航局遲延最後重要設計審核及在該審核會中仍有部分重要設計問題未解決，致系統基本設計無法完成，乃導致該計畫及程式無從擬具」等語，並未主張民航局要求TACC系統測試文件應依「CDRL 020測試計畫之格式及內容標準」撰寫，係屬約外要求且致遲延（見外放對「航空管制自動化系統」鑑定事項之說明第72頁），且本件於95年3月10日送鑑定後，迄至97年12月1日被上訴人雖仍陸續就各項鑑定事項補送資料，惟就此部分則未為主張及舉證。被上訴人迄至中科院完成鑑定後，始於99年10月11日具狀主張此部分為約外要求，應認已逾時提出有礙訴訟之終結，且被上訴人亦未舉證，其此部分主張，即屬無法證明而無可取，其主張此部分為約外要求，亦無可取。

㈢且查系爭契約之工作說明書SOW第5.5節「Test and Eval-

uation」規定「....Development Test and Evaluation(DT&E) testing shall be conducted in four phases:

CI and CPCI Tests (including System ConfidenceTests).Installation and Checkout Tests, Systemintegration Tests,and System Performance Tests.」, 並於第5.5.1節規定「Testing and documentation re-quirement are given in the following subparagraphs」，其第5.5.1.2節「Hardware Configuration ItemTests」規定「The contractor shall prepare andsubmit test plans and procedure for CI testing ofhardware in accordance with the CDRL....」，第5.5.

1.3節「Computer Program Configuration Item Tests」規定「The contractor shall prepare and submittest plans and procedure for CPCI testing of com-puter programs in accordance with the CDRL....」，第5.5.1.8節「System Integration Tests」規定「Thecontractor shall prepare and submit a test plan

and procedures for system intergration testing inaccordance with the CDRL....」，第5.5.1.9節「Sys-

tem Performmance Tests」規定「The contractorshall prepare a test plan and proceudres for sys-

tem preformance testing in accordance with theCDRL.....」，並於第5.5.3節「General Test Rules」規定「The following genreal test rules shall apply:

1.All formal testing shall be performed in accord-ance with CAA apporved test plans and precedures....」，明定就硬體結構項目、電腦程式結構項目、系統整合與系統執行等事項之測試，應依民航局核准之測試計畫與程序為之，且將電腦程式結構項目與系統整合及系統執行，並列為應一併測試之子項目（見本院卷十六第62至69頁，外放SOW第5-16頁至5-20頁） ，可知系統測試計畫與程序審查本即包含軟體程式測試計畫 （規範CPCI測試之CDRL 020文件），及系統整合及功能測試計畫（規範系統整合及執行測試之CDRL 020文件），並不限於CDRL 021文件。準此，洛克希德公司自應依相對應之CDRL 020與CDRL021文件進行撰寫TACC系統測試文件並提交審查。被上訴人主張要求TACC系統測試文件應依「CDRL 020測試計畫之格式及內容標準」撰寫，為屬約外要求，應無可取。

３、民航局有無遲延進行TACC系統測試文件「共同審閱（walkthrough）」會議，而違反定作人及時審核文件之協力義務？㈠被上訴人主張洛克希德公司於76年11月24日建議民航局就

CDRL 020資料項目之文件，採取雙方共同審閱（walk-through）之方式，民航局於77年1月19日函覆或可一試，洛克希德公司又於77年2月23日建議就TACC系統測試文件CDRL 021亦採取共同審閱方式，惟民航局未及時指示開會之時程，洛克希德公司於 77年5月24日再函請民航局進行共同審閱會議， 民航局始於77年6月4日指示於77年6月15日進行共同審閱會議，洛克希德公司因其公司人員於77年6月9日至6月21日間在美國，乃於 77年6月7日函請民航局改期，詎民航局於 77年6月25日終止契約，致TACC系統測試文件未完成審核云云。

㈡惟被上訴人於送請中科院鑑定時，就「系統測試計畫及程

序審查之遲延」，僅泛稱「此計畫及程式係為進行系統驗收測試而設，其必須俟系統之基本設計完成後而可擬具，惟由於民航局遲延最後重要設計審核及在該審核會中仍有部分重要設計問題未解決，致系統基本設計無法完成，乃導致該計畫及程式無從擬具」等語，並未主張民航局遲延進行TACC系統測試文件共同審閱會議，違反定作人及時審核文件之協力義務（見外放對「航空管制自動化系統」鑑定事項之說明第72頁），且本件於95年3月10日送鑑定後，迄至97年12月1日被上訴人雖仍陸續就各項鑑定事項補送資料，惟就此部分則未為主張及舉證。被上訴人迄至中科院完成鑑定後，始於99年10月11日具狀主張此部分為約外要求，應認已逾時提出。

㈢且查，依財團法人資訊工業策進會所編「驗證流程領域導

入指引」，及甄敏著「論審查（Review）方法之二─Walkthrough」之說明，在軟體發展過程中，「walk-through」係指「逐步審查」，並非被上訴人所稱之「共同審閱」，且係在一定要件下，由軟體之作者（於本件即為洛克希德公司）主導召集，並進行系統驗證（verification）之程序（見本院卷十六第303至310頁），被上訴人主張民航局未及時召集違反定作人之協力義務，應就TACC系統測試文件之審核負遲延責任，並無可取。

４、而此系統測試計畫及程序審查部分，送經中科院鑑定結果，亦認「系統測試計畫用來依規範驗收設計，即使設計有爭議，廠商仍應依所認知之規格與設計擬定測試計畫……洛克希德公司至74年11月26日始提出測試計畫格式及內容標準（延誤時間超過一年），該測試計畫撰寫標準民航局於74年12月5日表示同意。 ……洛克希德公司測試文件資料，並未依照上述標準撰寫，致使相關測試計畫及程序不合規定。 附件131號顯示，洛克希德公司自己承認：『未依規定按部就班先進行單元測試，以致系統有多項缺失』。不能完全歸究民航局部分重要設計問題未解決，致使系統基本設計無法完成，計畫及程式無從擬具。且洛克希德公司並未舉證證明民航局遲延最後重要設計審核及在該審核會議中仍有部分重要設計問題未解決，致使系統基本設計無法完成，計畫及程式無從擬具」等語（見外放鑑定報告第58至59頁）。

５、民航局既未延誤TACC之CDR，其要求TACC系統測試文件應依「CDRL 020測試計畫之格式及內容標準」亦非約外要求，且未因未及時召開Walkthrough會議而違反定作人及時審核文件之協力義務，則被上訴人主張其就此部分得依闡明條款第4.1條規定調整完工期限，及依闡明條款第4.2條第1項第2、3、4、6款規定，順延完工期限亦非可取。

（）關於被上訴人主張「長程雷達訊息介面定義不足」部分（中科院鑑定報告第三大項第1小項）：

１、被上訴人主張依List of ROC Furnished Equipment andServices （中華民國政府應提供之設備及服務，下稱GFE）第12條2項規定， 民航局應於簽約後即提供初步之長程雷達訊息資料格式，並應於簽約後五個月(即73年5月20日）內提供最終之長程雷達訊息資料格式，惟民航局未於73年5月20日前提供最終之長程雷達訊息資料格式， 反提出約外要求，要求洛克希德公司自行前往中華民國空軍基地，記錄真實長程雷達訊息資料，致TACC系統及空軍戰管中心系統間介面之設計及開發因而延宕，終而遲延系爭航管工程，依闡明條款第4.1條、第4.2條第1項第2、4、6款規定，其得要求合理調整或逐日順延完工期限云云。

２、按系爭航管契約之GFE第12條規定：「Item 12: DataFormats for Interface Planning: a.LRR message via

the ADC.b...f....Date Required: Need preliminarydata as soon after Contract Award Final 5 MAC」，即民航局最遲應於簽約後5個月內提供長程雷達訊息資料格式予洛克希德公司（見本院卷十六第216頁）。 而查，民航局已於 73年1月18日提供長程雷達訊號之介面定義資料格式予洛克希德公司，並經洛克希德公司簽收在案，有經洛克希德公司簽收之證明文件在卷可稽（見本院卷十六第217至218頁）。而觀諸民航局73年10月29日函稱「1.

The CAA has delivered to the LILT duringthe period

of 18 January 1984 to 3 March 1984, all the avail-able interface data asspecified in GFE Item 12.Attachmets A through C are copies of LILT's signedreciep.」 （見本院卷十六第219至220頁），及73年3月9日顯示設計會議紀錄載「2.The existing ADC test andservices messages were forwarded to Lockheed (Mr.

Joe Johnston) by the CAA (Ms.Jean Shen)...8.GFEItem 12f was given to Lockheed(Mr.Don Kinney) by

CAA (Ms.Jean Shen)」 （見本院卷十六第221頁），且締約雙方於74年8月8日第四次契約變更時，締約雙方亦再度確認GFE Item 12已由洛克希德公司收悉 （見本院卷廿一第313頁），民航局主張其已於73年3月3日以前將GFE第12條約定之文件全數交付洛克希德公司，應堪信取。

３、被上訴人雖以GFE第12條「Date Required」規定:「Needpreliminary data as soon after Contract AwardFinal 5 MAC」 ，主張民航局應於簽約後五個月內提供最終之長程雷達訊息資料格式，而未提供，且締約雙方於73年4月18日、5月30日、6月28日、8月15日介面設計會議中仍持續討論長程雷達訊息資料格式相關之事項，抗辯民航局未於簽約後五個月內提供最終之長程雷達訊息資料格式，且所提供者不明確且不特定，非長程雷達訊息資料格式之最終版本云云。惟查，系爭航管自動化契約之介面控制文件第5.1節「LRR Data Interface Function Character-istics」之5.1.1節「Message Characteristic」第5、6約定「5.The Air Defense System shall be capable ofsending LRR data messages at a continous and max-imum trans mission rate of 2400 bits per sencondwithout any loss of messages.The Air Defense Sys-

tem will be responsible for maintaining the inter-grity of the message text data.」、「6.The TACCautomation system shall be responsible for inter-preting the messages and structuring the messagesinto internal formats」 （見本院卷十六第222至224頁，外放介面控制文件第5-1、5-2頁），足見ADC系統與TACC系統間之相容性與資料及時傳輸問題，依約應由被上訴人負責解決。準此，GFE第12條「Data Formats forInterface Planning」之「Date Required 」:「Needpreliminary data as soon after Contract AwardFinal 5 MAC」之規定，應係指民航局最遲應於簽約後五個月內提供，非民航局應提出「Data Formats for In-terface Planning」之最終版本。否則，如依被上訴人所言「Data Formats for Interface Planning」 之最終版本應於民航局提出，締約雙方又何需於73年4月18日、5月30日、6月28日、8月15日介面設計會議中仍持續討論長程雷達訊息資料格式相關之事項？且於第四次契約變更時，確認GFE Item 12之各項已由洛克希德公司收悉 （見本院卷廿一第313頁）？上訴人主張民航局依GFE第12條規定，僅需提供初步之LRR訊號格式版本，應為可取。又被上訴人雖以73年4月18日、5月30日、6月28日、8月15日介面設計會議中雙方仍持續討論長程雷達訊息資料格式相關之事項，主張民航局所提供長程雷達訊息資料格式不明確且不特定云云。 惟查，依73年4月18日、5月30日、6月28日等歷次設計會議紀錄（見本院卷十七第21至44頁），兩造於會議中雖均有討論長程雷達訊號資料相關問題，但洛克希德公司並無確切說明民航局提供之資料不夠明確完整，致無法如期施工，被上訴人主張民航局提供之長程雷達訊息資料格式不明確且不特定，已非有據。且系爭航管自動化系統既由被上訴人負責設計建置，縱令其認為上訴人交付之資料不夠明確，其仍應設法解決並繼續進行相關之設計。被上訴人抗辯因上訴人提供之資料不明確，致其設計及開發因而延宕，終而遲延系爭航管工程，應非可取。

４、被上訴人雖又主張依72年9月24日第4次澄清會議第44項議案，民航局有義務提供真實的長程雷達訊號資料，惟竟反而提出洛克希德公司自行前往中華民國空軍基地，記錄真實長程雷達訊息資料之約外要求，致TACC系統及空軍戰管中心系統間介面之設計及開發因而延宕云云。惟被上訴人於送請中科院鑑定時，就此「長程雷達訊號介面定義之未提供」部分，並未主張民航局要求洛克希德公司自行前往中華民國空軍基地，記錄真實長程雷達訊息資料係屬約外要求（見外放對「航空管制自動化系統」鑑定事項之說明第73頁） ，且本件於95年3月10日送鑑定後，迄至97年12月1日被上訴人雖仍陸續就各項鑑定事項補送資料， 惟就此部分則未為主張。被上訴人迄至中科院完成鑑定後，始於99年12月29日具狀主張此部分為約外要求，應認已逾時提出，其主張此部分為約外要求，已屬無法證明。且查72年9月24日第4次澄清會議第44項議案載：「CAA wasrequested to investigate the possibility of provi-ding live rada data to LEC falility during develo-pment phase of the project」，固要求民航局研究提供真實雷達資料之可行性（見本院卷十七第67頁），惟被上訴人自陳真實長程雷達資料之提供， 原則上應依GFE第13條d款第4目等規定辦理（見本院卷十七第104頁） ，既與GFE第12條a款之LRR介面定義無關， 被上訴人以此主張民航局未盡提供長程雷達訊號介面定義之義務，已有不合。又民航局於74年1月22日會議中雖表示「PersonnelSecurity Clearance were processed for R.Williams

and D.Lee.The CAA requested that LILT submit arequest to visit with the people, equipment andinterface requirements defined....」，核係對於洛克希德公司派員紀錄實真實雷達資料之要求（見本院卷十七第74頁），所為回應，而要求洛克希德公司提交正式書面拜訪請求（見本院卷十七第86頁），上訴人主張民航局要求洛克希德公司自行前往空軍基地記錄長程雷達訊息資料，亦係為幫助洛克希德公司克服設計上遭遇之困境，非屬約外要求。

５、關此被上訴人主張「長程雷達訊號介面定義未提供」部分送請中科院鑑定結果，亦認 「依據附件132號，民航局於

73 年1月18日提交長程雷達介面資料給洛克希德公司，故民航局確已在期程內將長程雷達格式交與洛克希德公司，而洛克希德公司於73年3月9日在顯示設計研討會中（附件132號）確認已收到長程雷達資料，並於73年4月18日之後多次會議中研討長程雷達數據之相關資料；但從洛克希德公司提供之資料（原證262-265號）來看，原證264號民航局明白表示洛克希德公司設計不符需求，其餘資料顯示每次會議中，皆有討論到相關問題，惟並無確切說明洛克希德公司為何認為民航局所提供資料不夠明確完整，以致無法如期施工等情事。依慣例承包商依據使用者提供之初版界面文件後，若買方無法更進一步提供細部界面資料時，礙於合約時間壓力，應就既有文件進行設計。長程雷達系統雖為空軍使用，但該系統卻為休斯公司承包建置，洛克希德公司應掌握評估發展的介面是否能與先前規格相容，無法相容之風險應由該公司負擔」、「依據洛克希德公司所提佐證資料，並無確切說明該公司為何認為民航局所提供資料不夠明確完整，因此無從認定會導致無法如其期施包工等情事。依慣例承包商依據使用者提供初版之界面文件牛後，若買方無法更進一步提供較細部界面資料時，礙於合約目時間壓力，應就既有文件進行設計」（外放鑑定報告第60、61頁），上訴人抗辯民航局未依限提出長程雷達訊息資料，反提出約外要求，要求洛克希德公司自行前往空軍基地，記錄真實長程雷達訊息資料，致TACC系統及空軍戰管中心系統間介面之設計及開發因而延宕，終而遲延系爭航管工程，依闡明條款第4.1條、第4.2條第1項第2、4、6款規定，其得要求合理調整或逐日順延完工期限云云，應非可取。

（）關於被上訴人主張「長程雷達介面測試支援不足」部分（中科院鑑定報告第三大項第2小項）：

１、被上訴人主張依系爭航管契約工作說明書第4條、74年8月

8 日第四次修正之GFE第13條ｄ項第4款、TACC規格書第

3.1. 3.1節、及Terminal and Area Control CenterAutomation System Testing Concept （終端及區域控制中心自動化系統測試原則，以下稱測試原則） 第7.3.3節規定，民航局應於75年2月至4月間提供TACC系統與長程雷達間介面之數位通訊資料連接，其中包括10個真實長程雷達資料，俾洛克希德公司執行TACC系統與長程雷達間介面之整合及測試工作。惟民航局提出之長程雷達資料始終未達10個，且品質欠佳不適於用於介面測試，甚至提出約外要求，要求洛克希德公司以模擬之長程雷達資料執行介面測試工作，迄至77年6月25日系爭契約終止時，仍未提供符合品質、數量之真實長程雷達資料，致工程延宕云云。

２、查工作說明SOW第4條規定民航局應提供長程雷達介面系統予洛克希德公司 （見本院卷十七第129頁，外放工作說明第4-1頁） 、GFE第13條ｄ項第4款規定，民航局應自契約訂立後19個月，提供並維持TACC系統與長程雷達間之數位通訊資料連接，其中包括提供長程雷達資料，嗣於 74年8月8日GFE第四次修正時，上開19個月之期限修正為26至28個月，即75年2月至4月間（見本院卷十七第138頁） ，又摘明摘要第3.1.3.1節規定「the TACC shall be pro-vided the capability to interface with up to tenLRRs via the ADC...The Chinese Air Force and the

CAA will provide the digital data links required

to interface the ADC with the LRR sites.」（見本院卷十七第125頁，外放摘明摘要第3-12頁） 、另測試原則第7.3.3節規定「A test issuing live data fromradars will also be conducted.The radar data will

be obtained from aircraft of opportunity.The testwill verfy that the radar inputs function has beencorrectly adapted and that tracking of live air-craft can be performed. Verification of the TACC

and TCC OCP adaption data for rho/theta filters

and rata mosaics will be accomplished by a combi-nation of analysis and live tests.」（見本院卷十七第121至122頁，外放測試原則第7-27、7-28頁），被上訴人主張上訴人應於75年2至4月間提供長程雷達資料，固為可取。

３、惟查系爭航管契約被上訴人投標文件第三冊Section 1 第

3.1.1節「Testing Program Plan（測試程式計畫）」 約定「....LEC's testing will be facilitated if CAAprovides LEC with live radar signals, but ourproposal is not constrained by this request....Simulated and recorded radar inputs will also beused for CPCI testing for cases where reproduci-bility is of prime importance (such as trackingperformance) or because live radar is not avail-able」（見本院卷十六第228頁，外放投標文件第三冊Section 1第3-5頁），上訴人主張依契約相關約定關於長程雷達之測試支援，若無法取得真實之雷達資料時，得使用模擬之雷達資料進行測試，尚非無據。則被上訴人主張民航局提出由洛克希德公司以模擬之長程雷達間介面資料執行介面測試之要求為約外要求，其得依闡明條款第4.1條規定調整完工期限，即非有據。

４、查民航局於76年1月22日去函洛克希德公司稱：「...Webelieve Lockheed should be using simulated notlive,data fo software development at this time.Theradar quility is of major concern to the CAA, and

we are strivinig to improve is. However, if we areunable to eliminate the problems cited in CDRL001

by time of TACC system acceptance, we may have toaccept the system without adquiately validating

its processing of live radar data.」，表示依當時狀況被上訴須使用模擬，而非真實之雷達資料，並說明若雷達資料之品質未經改善，民航局將接受未經真實雷達資料充分驗證之系統（見本院卷十六第230頁）；嗣又於77年2月25日去函洛克希德公司重申：「3. As eraly as 22January 1987...and several times since then, the

CAA has stated their belief that Lockheed should

be using simulated not live,long-range radar data

for software development...4. The CAA has statedrepeatedly that, in the event any Governementfurnished interfact, including radar, fails tomeet its specified performance criteria at thetime the TACC is to undergo the formal testingleading to acceptance of the system, the CAA isprepared to accepted the system bassed uopn test-

ing that uses simulated inputs.」 （見本院卷十六第231至232頁），已表示若正式測試系爭航管自動化系統而雷達資料仍未能滿足特定之執行標準時，民航局將接受經模擬資料驗證之系統，則洛克希德公司如認民航局提供之真實長程雷達資料，數量不足、品質不佳，無法使用以執行TACC系統與長程雷達間介面之整合及測試工作，應即可使用模擬之雷達資料進行測試。而以模擬資料進行測試，可某種程度上免除以真實資料測試之相關變數及突發狀況，且洛克希德公司對於模擬器與系爭航管系統及周邊系統間之配合度與整合性等問題，更能事先掌握，可降低驗收不合格之風險，於洛克希德公司更為有利。

５、此部分經中科院鑑定結果，亦認 「依合約（GFE表第13項第d款第4目）民航局應提供長程雷達訊號連接之相關設備與訊號，然民航局於76年1月22日及77年2月25日發函（附件134、135）中，皆述明此項測試可視真實雷達信號狀況調整，必要時可採用模擬雷達信號來執行測試，民航局將予以認可。又洛克希德公司提出之建議書 （附件133號）已載明，該公司有能力用模擬及錄製之資料作測試。本鑑定項目之焦點應著重於如何完成此項測試，若洛克希德公司主張以真實雷達信號來作為系統測試輸入信號，依本院雷達發展經驗，該公司所提之（ii)、(iii)、(iv)、(v)項目係屬真實雷達正常狀況，該公司於設計時本應納入考量，不可依此認為支援不足，而指控民航局未提供十個雷達信號。以軟體發展經驗法則觀之，發展過程中必須同步發展週邊介面模擬器來測試該發展係統，待真正驗收測試時再連接真實環境系統作測試。若買方同意以模擬器來執行驗收測試，對賣方而言將是求之不得，因為使用模擬器來執行驗收測試的風險將比連接真正的週邊系統來得低」、「依上所述，民航局既然同意採用模擬雷達訊號來執行測試，因此洛克德公司認為雷建訊號量不足質不佳之事項，將致使一般承包商無法進行整合與測試，並不合理」等語（見外放鑑定報告第61、62頁）。被上訴人主張其可依闡明條款第4.2條第1項第2款、第4款、第6款展延完工期限，亦非可取。

（）關於被上訴人主張「飛航資訊服務系統介面定義遲延提供」部分（中科院鑑定報告第三大項第3小項）：

１、被上訴人主張依GFE第12條e項規定，民航局應於 73年5月20日前提供最終之飛航資訊服務系統（Flight Informa-tion Services System，下稱FISS系統）之介面定義；另闡明摘要附表3-3「Message Source Eligibility （訊息來源資格）」明定TACC系統應與8項系統交換訊息，TACC系統與FISS系統應交換之訊息類型為24種。惟民航局未依限提供，並一再變更其FISS介面定義，遲至75年5月8日始提供最終FISS介面定義；且提出約外要求，指示洛克希德公司修改TACC系統及TCC系統之設計以符合國際民航組織文件第12版之規定， 並要求將8項系統擴增為11項系統，將TACC系統與FISS系統交換之訊息擴增為36種，致雙方須長期反覆討論、澄清，導致TACC系統之軟體及韌體設計因而一再變更而遲延，系爭工程並因此延宕，其得依闡明條款第4.1條、第4.2條第1項第2、4 、6款規定， 其得要求合理調整或逐日順延完工期限。

２、查GFE第12項ｅ款規定，民航局最遲應於簽約後5個月內提供FISS之介面定義予洛克希德公司 （見本院卷十六第216頁），而兩造係於72年12月20日簽約，故民航局應於73年5月20日前提供FISS系統之介面定義予洛克希德公司。 而查，民航局已於 73年1月18日提供FISS介面定義予洛克希德公司，並經洛克希德公司簽收在案，有經洛克希德公司簽收之證明文件在卷可稽（見本院卷十六第217至218頁）。民航局73年10月29日函並稱「1. The CAA hasdelivered to the LILT during the period of 18January 1984 to 3 March 1984, all the availableinterface data asspecified in GFE Item 12.Attach-ments A through C are copies of LILT's signedreciept.」（見本院卷十六第219至220頁），且締約雙方於 74年8月8日第四次契約變更時，締約雙方亦再度確認

GFE Item 12e項FISS interface definition 已由洛克希德公司收悉（見本院卷廿一第313頁） ，民航局主張其已於73年3月3日以前將GFE第12條e項約定之FISS文件交付洛克希德公司，並無遲延，應堪信取。

３、又CAA-E-IC-004,Revision 1「Preliminary Taipei AreaControl Center Automation System/FlightInformationService System Interface Control Document（以下稱飛行資訊系統介面控制文件）第3.4節規定「The TACCautomation system will receive from and transmit

to the AIMS the ATS(Air Traffic Service)messages

as definied vy ICAO(PANS-RAC ICAO DOC 4444-RAC/501/11）.TACC系統應從AIMS系統接受並傳送國際民航組織文件4444-RAC/501/11（即第11版） 所定義之航管服務訊息」（見外放飛行資訊系統介面控制文件第3-6頁）， 被上訴人主張有關飛行資訊系統介面之設計，應以國際民航組織文件第11版為依歸，固非無據。又民航局雖於74年10月

22 日函文中指示洛克希德公司修改TACC系統及TCC系統之設計以符合國際民航組織文件4444-RAC/501/12 （即第12版）之規定（見本院卷十七第281頁） ，惟經洛克希德公司於74年10月24日發函告知對於成本及時程之影響後（見本院卷十七第284頁） ，民航局隨即於74年11月11、12日之執行審查會議中，表示撤回上開指示（見本院卷十七第294頁） ，民航局既於洛克希德公司告知影響後，即撤回此部分之指示。況依洛克希德公司投標文件第2冊Section1-TACC第4-6頁已載明「In designing this interface,

LEC has been mindful and considered the allowable

or pending changes to certain technical and opera-tional standards of ICAO.」（見本院卷廿四第188頁），明定洛克希德公司於從事設計工作時，對於特定技術標準與ICAO即國際民航組織操作標準之變動，必須顧及並納入考量，可知洛克希德公司本即應將ICAO相關文件之改版事宜納入設計之參考，期與國際接軌，以確保航空管制之實效性與安全性。被上訴人復未舉證證明洛克希德公司有因該項指示而暫停進行中之設計工作、投入國際民航組織文件第12版之研究，其以民航局提出約外要求，主張可依闡明條款第4.1項調整完工期限，自無可取。

４、再查，TACC規格書第3.1.3.3節規定「The TACC shall beprovided the capability to interface with theFlight Infomation Service System (FISS) computer.This interface will be used for the exchage offlight data,weather data, PIREP message, and NOTAMmessages....The TACC/FISS interface information iscontained in CAA-E-IC-004, Rev, 1.（TACC系統應具備與FISS系統介接之功能，此一界面應用於飛航資訊、氣象資訊、飛行員報告資訊及飛航公告資訊之介接……TACC/FISS界面所應交換之資訊，詳見CAA-E-IC-004(第1版)」（見本院卷十六第234頁，外放TACC規格書第3-13頁）。

而CAA-E-IC-004（第1版)即飛行資訊系統介面控制文件第

1.2節規定「This document defines the characteris-tics of the hardware, soft- ware and operationalelements that are necessary for the timely andefficient trnasfer of data between the TACC auto-mation system and the FISS」 ，規定TACC/FISS界面應具有及時、有效於TACC系統與FISS系統間傳遞資訊之軟硬體特徵及操作諸元， 並於3.2節，將FISS系統進一步細分為自動交換訊息系統AIMS等四個子系統， 復於第5.1節明定AIMS與TACC間系統交換傳輸之資訊，包含distressmessages and distress traffic（災難資訊與交通）、urgency messages（緊急資訊）、flight safetymessages（飛安資訊）以上三者合稱為ATS Message飛航服務資訊，及meteorological messages（氣象資訊）、PIREPS飛行員報告資訊、NOTAMS飛航公告資訊與service

and support messages服務及支援資訊等七類資訊（見本院卷十六第236頁、238至239頁、第214頁，外放飛行資訊系統介面控制文件第1-1頁、第3-1頁、第3-2頁、第5-1頁）。且每個資訊形式又細分為數十個細項資訊之形式，如

ATS Message包括24種訊號形式、氣象資訊包含8種訊號形式、氣象預報包含5種訊號形式、氣象觀測又分為例行天氣報告與機場特別天氣報告，而各含11種及7種訊號形式、飛行員報告資訊亦至少含有7種訊號形式（見外放飛行資訊系統介面控制文件第5-41頁、第5-61至69頁、第5-72頁），合計TACC/FISS界面所應交換之訊號形式不止36項，被上訴人以TACC規格書及闡明摘要3-3表格僅列24項，主張TACC/FISS界面所應交換之訊號形式僅有24項，忽略飛航資訊系統介面控制文件規定之相關項目，應非可取。上訴人主張其僅去函被上訴人說明，並非提出約外要求，亦非修正FISS介面定義，尚非無據。

５、被上訴人雖主張民航局於 74年4月10日函中自承TACC規格書關於TACC/FISS系統介面之規定曖昧不明云云。 查民航局74年4月10日函稱「1.1 LILT apparently is confusedregarding TACC/FISS message exchange. Admittedlysome of this stems from verbiage in the TACC sys-

tem specification whereinTACC/FIC,TACC/FIS,TACC/

Met.,Center, etc. categorues are cited for messageexchange. As the TACC system specification wasdeveloped some time before the FISS system spcci-fication and a longer time before the FISS confi-guration was developed the verviage used is, insome cases, inappropriate or at least misleading.（洛克希德顯然混淆了有關TACC/FISS電報交換之用語。

明顯地這是源於TACC系統規範中引用在電報交換中的一些單位用語，如TACC/FIC（情報中心）、TACC/FIS（諮詢臺）、TACC/Met.（氣象中心）等類別所致。由於TACC 系統規範較FISS系統規範更早發展，且比FISS系統配置使用的用語更早使用，在某些情況下，用詞會出現不適當或至少誤導之情形）」 （見本院卷十七第351頁），核其內容係以委婉之方式指出洛克希德公司混淆了系統對系統（TACC/FISS）及單位對單位（TACC/FIC、TACC/FIS、TACC/Met.）在電報交換用語上之問題，被上訴人以此主張TACC規格書關於TACC/FISS系統介面之規定曖昧不明云云，應為可取。

６、就此上訴人主張飛航資訊服務系統介面定義遲延部分，經送中科院鑑定結果，亦認 「就原證一九五號第3.1.3.3資料觀之，飛航諮詢服務系統（FISS) 之介面，須用於飛航資料、氣象資料、PIREP資料、NOTAN資料之介接，此外更須與AFTN網路、氣象中心、飛航資訊站相連接。另依附件一三八號資料(CAA-E-IC-004系統介面控制文件) 中之5-1與5-3頁，對各項資訊需求狀況加以分別說明，指出系統需交換的資訊包括Distress Message and DistressTraffic(災難資訊與交通), Urgency Messages（緊急資訊)、Flight Safetfety Message(飛安資訊)、Meteoro-logical Messages(氣象資訊)、PIREP資料、NOTAN資料、Sevice and Supply Messages(服務與支援資訊)。總計細項超過24項，而洛克希德公司認為只有24項飛航諮詢服務系統資訊連接需求，係對於本工程案系統需求無詳細瞭解。 原證十號中第5頁資料顯示，民航局需於簽約後五個月內提出飛航資訊服務系統介面定義資料。而本工程案係於72年12月10日簽約，因此民航局須於 73年5月10日前提出。 惟依附件一三二號中Attachment A顯示民航局在73年1月18日 CAA-GFE-001中已將GFE第12項e款飛航資訊服務系統(FISS)介面定義提供給洛克希德公司，民航局確實在規定之時間內內 73年5月10日前完成此項工作，此部分並無延遲交付之情事。74年10月22日民航局通知洛克德公司依最新修正ICAO(國際民航組織)程序，修改各項訊息格式（附件一三六號），但民航局隨即於74年11月29日撤回74年

10 月22日之修改決議，回復原有需求，此時CDR尚未召開，尚屬合情合理。洛克希德公司在此期間所稱投入大量人力設計，無相關佐證資料認定（見外放鑑定報告第63頁）。民航局既未提出約外要求，且已依限交付FISS介面定義，則被上訴人主張其可依闡明條款第4.2條第1項第2、3、

4 、6款規定順延完工期限，應無可取。

（）關於被上訴人主張「飛航資訊服務系統介面測試支援中斷及不足」部分（中科院鑑定報告第三大項第4小項）：

１、被上訴人主張依GFE第13條ｄ(4)項規定民航局應於75年2月至4月間備置一套功能完整之FISS系統，且應持續維持該系統，俾供洛克希德公司進行系爭航管工程之各階段測試工作，惟民航局向訴外人TITN公司採購之FISS系統功能不全，且嗣民航局與TITN公司終止契約，FISS系統於76年初遭TITN公司拆除，民航局遲至76年6月間始提供一套模擬FISS系統，惟該系統不符合「實際情況（realisticconditions）」之測試原則及真實飛行計畫（live fightplan）之測試環境要求，因該有瑕疵之模擬FISS系統欠缺完整功能，相關測試工作因而窒礙難行且下耗費大量人力、時間進行校正、偵錯，嚴重影響系爭航管工程之相關測試工作，並導致工程進度遲延，其得依闡明條款第4.1條及第4.2條第1項第2款及第6款規定展延完工期限云云。

２、查工作說明（SOW）第4條規定「CIVIL AERONAUTICSADMINISTRATION RESPONSIBILITY:...3.provide or makeaccessible, the following interfacing systems with

the TACC:...c. The FISS;」（見本院卷十七第352頁，外放SOW第4-1頁），又GFE第13條Test support之ｄ款TACC/TCC Equipments之(4)規定「Item: The CAA shallprovide and maintain end-to-end termination of thedigital communication data link interfacts between

the TACC buildiint and the interfacing systems(LRR,the ADC, FISS),and the Flight Service Statuibs atChiang Kai-Shek Airport, Taipei, Kaohsing,Hualien

and Makung. Date Required:26-28 MAC FEB-APR 1986」（見本院卷十七第358頁） ，兩造係於72年12月20日簽約，故被上訴人主張民航局應於 75年2月至4月間提供一套FISS系統，並持續維持該系統，固為可取。

３、惟為驗證TACC系統與FISS系統間之整合性，在TACC系統進行整合執行測試（Formal Integration & PerformanceTesting，下稱整合測試） 期間，民航局自須提供可與TACC系統進行整合測試之FISS系統供驗證洛克希德公司所建置之TACC系統。惟依 74年8月8日契約第四次修正之 「TACC TEST SCHEDULE」所示，TACC系統在與FISS系統進行整合測試前，需先通過「正式電腦程式結構項目信心測試（Formal CPCI Testing，下稱信心測試）」 ，而系爭契約於第四次修正時，將TACC系統之信心測試期間延至76年2至6月間，整合測試期程延至76年6至9月間（見原審原證卷一第40頁）。而系爭契約之工作說明書SOW第5.5節「Test and Evaluation」規定「The Test and Evaluationprogram shall satisfy all test requirements ofSection 4 of the Specifications and the conceptdescribed in CAA-ET-CD-001,Rev.2. and shall....Development Test and Evaluation (DT&E) testingshall be conducted in four phases: CI and CPCITests (including System Confidence Tests).Instal-lation and Checkout Tests, System integrationTests,and System Performance Tests.」（見本院卷十六第65至66頁，外放SOW第5-16、5-17頁）。惟洛克希德公司於74年11月26日提出「Format and Content Guide

for the Test Plans（系統測試計畫格式及內容指南」（見本院卷十六第70頁），惟嗣後洛克希德公司並未依該指南撰寫相關測試文件，致測試時出現諸多缺失，迄至76年3月25日仍無法通過審查 （見本院卷十六第70至79頁民航局76年3月25日及77年1月19日函），洛克希德公司亦自承「單元測試之問題狀況為有些編碼模組欠缺足夠之單元測試，或遺漏部分軟體專案管理過程中，紀錄各工作項目之設計、編碼、測試與整合（Unit Development Folder ）之步驟（Questionable Status of Unit Test.There isconcern that some code molules lacked sufficientunit testing, or that the UDFs were not maintained

or are missing」（見本院卷十六第80頁）。洛克希德公司既未通過信心測試，而無法進行後續之FISS系統進行整合測試，則民航局縱未於GFE第13條ｄ款(4)規定之 75年2月至4月間提供FISS系統，亦不致影響系爭航管工程之相關測試工作，而造成系爭工程進度遲延。

４、又民航局向訴外人TITN公司購買之FISS系統雖遭TITN公司拆除，惟嗣民航局已於契約第四次修正規定之整合測試期間內之 76年6月間，提供由Unitech公司發展之完全擬真FISS系統予洛克希德公司為被上訴人所自承（見本院卷十七第359），洛克希德公司應即得接續為TACC/FISS系統整合測試，而無支援中斷之問題。被上訴人雖主張民航局應提供真實之FISS系統以與TACC系統進行整合測試，並主張民航局所提模擬FISS系統有瑕疵且不合格云云，惟被上訴人並未舉證該模擬FISS系統有何瑕疵及該瑕疵如何致整合測試無法進行，既經民航局否認，即難信取。被上訴人雖又主張以模擬FISS系統測試，不符合實際情況之測試原則及真實飛行計畫之測試環境要求云云，惟以模擬系統進行測試，可某種程度上免除以真實系統試之相關變數及突發狀況，且洛克希德公司更能掌控測試之進行，降低測試不合格之風險，於洛克希德公司應屬有利。

５、此部分經送中科院鑑定結果，亦認 「由於民航局與TITN公司終止合約，造成FISS系統無法及時支援TACC整合及性能測試，民航局於 76年7月27日去函洛克希德公司，委託Unitech公司發展一模擬FISS系統， 此一模擬FISS系統雖然為一過渡性系統， 是用來協助洛克希德公司進行發展TACC整合及性能測試用，作為相對應之補救措施。本工程案已於74年7月30日第四次修約，將測試期程延至76年6月至9月執行，因此民航局於76年7月27日之間提出模擬FISS系統執行測試，仍屬測試期間內。因此洛克希德公司以模擬系統不足以符合實際需求為藉口，遲遲進行TACC整合及性能測試，係造成飛航資訊服務系統介面連接測試支援中斷及不足之原因，並不合理」、「洛克希德公司認為民航局所提供模擬系統無法提供與真實系統相同之測試環境，致一般承包商均無法藉該模擬系統按時完成介面連接測試之情事，仍缺乏詳細佐證資料，故無法判定。然民航局同意依該局所提供模擬FISS系統進行TACC整合及性能測試，洛克希德公司基於賣方立場應無異議之理由」等語（見外放鑑定報告第65至66頁）。被上訴人主張其得依闡明條款第4.1條及第4.2條第1項第2款及第6款規定展延完工期限，非有理由。

（）關於被上訴人主張「狀況顯示器之迷你一覽表之約外要求」部分（中科院鑑定報告第四大項第1小項）：

１、被上訴人主張TACC及TCC規格書均未約定狀況顯示器（Situatiion Display，以下稱SD）應配置迷你一覽表，簽約時雙方就此亦未達成協議，故迷你一覽表並未列於闡明摘要或其他契約文件中，非系爭契約約定之功能，民航局於 75年8月14日要求於SD增加迷你一覽表，為屬約外要求。民航局並已於 76年7月14日TACC CDR待辦事項解決會議中自承迷你一覽表為約外要求，然卻於同日指示勿於狀況顯示器增加迷你一覽表，致洛克希德公司須放棄原依民航局新增迷你一覽表指示所為相關設計，重新進行大幅度變更、修正，致延宕系爭航管工程。

２、查洛克希德公司投標文件第二冊Engineering Section 1第2.2.1.1節Situation Display約定「...The trackball

is a hand-operated ball which, when moved,causes asymbol to move in the direction the ball is moved.....This process allows the controller to selectparticular targets for further messages or controlinputs, and allows him to position data lists any-where on the screen.（追蹤球須為手動之圓球，當圓球移動時，需使SD上之標誌依圓球移動方向動作……該程序將允許控制人員選擇特定目標以獲取進一步之相關資訊或控制輸入，並使控制人員可在螢幕任何區域，定位相關之資料列表）」 （見本院卷廿一323頁，洛克希德公司投標文件第二冊Engineering Section 1第2-43頁）。 又上訴人於簽約前之72年9月29日第7次技術澄清會議中，要求洛克希德提供SD之相關資料，並列為待辦事項第50項（見本院卷十六第256頁），洛克希德乃於72年11月7日就SD相關問題提出說明：「Situation Display Touch on MainScreen Option:The proposed touch on main displaycapability option is fully complaint with para-graph6.10. Although this design has also not beencompleted, as a minimum the touch-on main screenwould replace the trackball as the locating/point-

ing device for the radar controller.Additionally,

a list area of a selected subset of OAK's would belocated on the main display surface to providecapabilities similar to the Singapore system.」（見本院卷十六第260頁） ，已表示顯示器之螢光幕上將存在某一可顯示快速鍵之表列區域，並說明將以觸控螢幕之方式取代追縱球進行操作，上訴人主張兩造於簽約前已確認SD應具備一「表列區域」之功能，應為可取。

３、又簽約時於GFE第18項Display Format Definition約定「

Two months after contract award CAA, and LEC and

its display Subcontractor will convene a displayconference and define display formats to bedelivered to LEC by CAA」（見本院卷十七第495頁），而被上訴人於簽約後之73年3月8日顯示器設計會議中，表示顯示器之觸控功能，將透過顯示器螢幕上的menu（一覽表）執行，該一覽表可放置7筆資料，此觀會議記載「Mr.

Jim Devenney presented a description of the situa-tion display touch functions...It was resquestedthat Magnavox provide a list of function thatcould be performed from a menu on the situation,

the CAA staff will then identyfy which of thesefunctions are desirable for each sector (radarcontrol position)。A maximum of seven entries will

be provided for each menu.」之記載即明（見本院卷十六第261頁）。 則上訴人於75年7月23日表示應於ATC-914設計文件加入迷你一覽表，及於75年8月14 日要求將迷你一覽表增加於SD（見本院卷十七第447、451頁），尚難認係提出約外要求。

４、被上訴人雖主張民航局於 76年7月14日TACC CDR待辦事項解決會議中承認迷你一覽表為約外要求，惟為上訴人所否認。查76年7月14日TACC CDR待辦事項解決會議上「CA14-

SDC TOMS "Mini Menu" Document」記載：「Solution：

CAA agreed with Lockheed's position that the TOMS" Mini Menu" function need not be implemented inTACC or TCC（民航局同意洛克希德的立場，迷你一覽表於TACC或TCC系統不必實施」，民航局僅同意洛克希德公司不必施作迷你一覽表，並未承認迷你一覽表為約外要求（見本院卷十七第472頁），上訴人則稱同意洛克希德公司不必施作，是基於交期的考量，非因為此約外需求等語（見本院卷十七第399頁背面），被上訴人主張民航局已承認迷你一覽表為約外需求，尚非可取。

５、此部分經送中科院鑑定結果，亦以「附件164號，72年9月29日在合約簽訂前第七次需求澄清會時，民航局要求洛克希德公司提出狀況顯示器的相關資料(action item 50)。

附件一六五號顯示，洛克希德公司於 72年10月3日與72年11月7日，就狀況顯示器提出說明， 其中在主螢幕上觸控功能中提到狀況顯示上方有一表列區(迷你一覽表)可顯示快速功能鍵，且以觸控方式取代追蹤球操作。在73年3月8日顯示器設計會議中(附件一六六號)，會議記錄中記載洛克希德公司就狀況顯示器之觸控功能說明外，也提及在狀況顯示器上提供一覽表（Menu）至多可置放7筆資料（Entry)，請Magnavox公司提供一可置於狀況顯示器上一覽表(Menu)中的功能項目表列，以利民航局人員決定將那些功能置於一覽表（Menu），由此可見狀況顯示器設計研討中已將此狀況顯示器之迷你一覽表需求提出，所以此項功能並未超出基本需求規章範圍。經查附件一六七號，民航局於75年8月14日正式函請洛克希德公司將上述迷你一覽表功能，列在相關設計文件中。附件一六九號本工程案簽約協議書中，經雙方同意之協議，係為合約之一部分，故本項功能確實未超出基本需求規章範圍，故狀況顯示器之迷你一覽表係經雙方協議同意，並非約外需求」，而認「狀況顯示器之迷你一覽表係經雙方協議同意，並非約外需求」等語（見外放鑑定報告第67至68頁）。

６、此部分既非約外要求，上訴人主張其得依闡明條款第4.1條調整完工期限，即非有據。又此部分既非約外要求，自無所謂闡明條款第4.2條第1項第6款 「超出民航局、美商洛克希德電子公司及／或其等所指定之要次承包商合理控制範圍外之事件所致之任何遲延」之問題。又民航局嗣因系爭工程交期之考量，同意洛克希德公司不必施作迷你一覽表，亦難認有何闡明條款第4.2條第1項第4款所定 「民航局未能依約及時完成於本契約下之任何其他義務」之情形，被上訴人主張就此部分其得依闡明條款第4.2條第1項第4款、第6款展延完工期限，亦無可取。

（）關於被上訴人主張「待辦工作項目對於作業電腦程式之影響」部分（中科院鑑定報告第四大項第2小項）：

１、被上訴人主張依GFE第18條規定，民航局應於73年3月20日前提出顯示器格式定義，惟民航局未依限提出，故該等事項乃於TACC PDR期間列為待辦事項13、36、51、52、61及72號。 民航局雖於73年10月至74年7月間提出顯示器定義格式，惟其所提顯示器定義格式中包含大量約外要求，其中⑴待辦事項第13號單機飛航操作說明，提出多達40項之約外要求；⑵待辦事項第36號狀況顯示器列表格式，提出「降落列表列出6到7個次列表」之約外要求；⑶待辦事項第51號計畫管制顯示器之管制區域內陣列顯示器之資料區，提出「新增領域及使用中跑道」、「將原置於歸航資料顯示器之一般訊息及氣象資料，改置於管制區域內陣列顯示器，而擴增管制區域內陣列顯示器應顯示之內容」之約外要求；⑷待辦事項第52號計畫管制顯示器之歸航資料顯示器，提出歸航資料顯示器增加4個警報區域及一個要求區域，並增加邏輯顯示及顯示優先順序之約外要求；⑸待辦事項第61號顯示時間間隔之規格，提出「淨空處理」及「移轉警示處理」之約外要求；⑹待辦事項第72號標示及/ 或強調定義，提出「將格式數量由4增加為8」、「顯示器螢幕以垂直分離器分割」等14項約外要求，致相關作業電腦程式須配合變更、修改，延宕系爭航管系統之設計及開發，其得依闡明條款第4.1條、第4.2條第1項第2、4、6款規定展延完工期限。

２、被上訴人主張依GFE第18條規定，民航局應於73年3月20日前提出顯示器格式定義，但民航局未依限提出，惟為上訴人所否認。查GFE前言記載「The following is a list-

ing items that are to be furnished by CAA to sup-port development and implementation of the TACC

and TCC Automation」，並將「Display Format Defini-tion」列為Item 18，且於「Date Required」記載「3MAC」，惟Item 18「Display Format Definition」項下亦載明「Two months after contract award CAA, and LEC

and its display Subcontractor will convene a dis-play conference and define display formats to bedelivered to LEC by CAA」（見本院卷十七第495頁），狀況顯示器之格式定義，既係於簽約後由民航局、洛克希德公司及其次承包商共同召開會議研定後，再由民航局提交洛克希德公司， 顯然民航局依GFE第18條規定雖有提出狀況顯示器格式定義之義務，但該格式定義非由民航局單方決定提出，而係由三方研商決定後，再由民航局交予洛克希德公司執。 又洛克希德公司投標文件第二冊「Engi-neering Section 1」第2.2.1.2節「Tabular and Infor-mation Display」約定「The final version of thislayout will be reviewed and finalized at the Pre-liminary Design Review（PDR）」（見本院卷十四第64頁，外放洛克希德公司投標文件第二冊EngineeringSection 1.2-50頁），上訴人主張狀況顯示器之具體功能與最終格式， 依約應於PDR中由雙方共同研商確定，尚非無據。 則民航局能否於簽約後三個月提出，端視PDR進行之狀況，非民航局可單方任意提出， 縱因PDR進行之狀況無法於簽約後三個月內提出，洛克希德公司及其次承包商亦有責任，非可全歸責於民航局。

３、被上訴人雖主張民航局於TACC PDR期間，於⑴待辦事項第

13 號單機飛航操作說明，提出多達40項之約外要求；⑵待辦事項第36號狀況顯示器列表格式，提出「降落列表列出6到7個次列表」之約外要求；⑶待辦事項第51號計畫管制顯示器之管制區域內陣列顯示器之資料區，提出「新增領域及使用中跑道」、「將原置於歸航資料顯示器之一般訊息及氣象資料，改置於管制區域內陣列顯示器，而擴增管制區域內陣列顯示器應顯示之內容」之約外要求；⑷待辦事項第52號計畫管制顯示器之歸航資料顯示器，提出歸航資料顯示器增加警報區域1至4及一個要求區域，並增加邏輯顯示及顯示優先順序之約外要求；⑸待辦事項第61號顯示時間間隔之規格，提出「淨空處理」及「移轉警示處理」之約外要求；⑹待辦事項第72號標示及/或強調定義，提出「將格式數量由4增加為8」、「顯示器螢幕以垂直分離器分割」等14項約外要求云云，惟查：

㈠待辦事項第13號單機飛航操作說明部分，民航局提出「單

機飛航操作說明」之要求，並非約外要求，業經敘明於五

（）。㈡待辦事項第36號狀況顯示器列表格式部分，民航局提出「

降落列表列出6到7個次列表」並非約外要求，業經敘明於五（）。

㈢待辦事項第51號計畫管制顯示器之管制區域內陣列顯示器

之資料區部分，民航局提出「於完整資料欄新增使用中跑道功能」，並非約外要求，業經敘明於五（）。至於「新增領域」及「將原置於歸航資料顯示器之一般訊息及氣象資料，改置於管制區域內陣列顯示器，而擴增管制區域內陣列顯示器應顯示之內容」部分，被上訴人於送請中科院鑑定時，就此部分僅稱「民航局依合約中『中華民國應提供之設備及服務一覽表』 （GFE）中第18項，應提供顯示器格式資料，並在民國73年初期設計審核會議中列入待辦工作項目第36.51.52項，以配合洛克希德之電腦程式設計，民航局卻要求洛克希德應提供，易言之，民航局將本應由其提供GFE之顯示器格式資料， 強要求洛克希德提供」云云（見外放對「航空管制自動化系統」鑑定事項之說明第83頁），並未就上開部分為具體之主張，亦未主張民航局有提出約外要求，復未提出相關佐證資料。而此部分是否屬於約外要求，非經航空、通訊、資訊專業人員，以其專業依契約及相關往來文件研析，無法判斷，被上訴人迄至中科院完成鑑定後，始於99年12月29日具狀主張此部分為約外要求，應認已逾時提出有礙訴訟之終結。被上訴人亦未舉證具體說明各該事項之內容為何、何以該部分為約外需求，而關於待辦事項第51項，經成大航太所鑑定結果，亦認非屬約外要求（見外放成大補充鑑定報告第80頁）被上訴人主張此部分為約外要求，即無可取。

㈣待辦事項第52號計畫管制顯示器之歸航資料顯示器部分，

被上訴人主張民航局提出歸航資料顯示器增加4個警報區域及1個要求區域，並增加邏輯顯示及顯示優先順序 ，為屬約外要求，惟此部分經中科院鑑定結果，認非屬約外要求（詳見後述，及外放鑑定報告第69至70頁）。且關於待辦事項第52項，經成大航太所鑑定結果，亦認非屬約外要求（見外放成大補充鑑定報告第80頁）被上訴人主張此部分為約外要求，即無可取。

㈤待辦事項第61號顯示時間間隔之規格，民航局提出「淨空

處理」及「移轉警示處理」並非約外要求，業經敘明於五

（）。㈥待辦事項第72號標示及／或強調定義，被上訴人主張民航

局提出「將格式數量由4增加為8」、「顯示器螢幕以垂直分離器分割」等14項要求部分，被上訴人於上訴人提起本件訴訟迄中科院完成鑑定前，並未主張，而關於待辦事項第72項，經成大航太所鑑定結果，亦認非屬約外要求（見外放成大補充鑑定報告第80頁），被上訴人主張此部分為約外要求，亦無可取。

４、關於此被上訴人主張「待辦之工作事項對電腦作業程式之影響」部分，經送中科院鑑定結果，亦認「顯示器格式提供之責任及時間，乃民航局、洛克希德公司及其次合約商Magnavox三方共同負責，顯示器格式之訂定有延後之事實，但仍在可接受之範圍內。洛克希德公司聲稱民航局強要其提出顯示格式資料，卻無提出相關佐證顯示民航局有強要之作為，因此洛克希德公司『待辦之工作項目對電腦作業程式之影響』之控訴，應屬不當」等語（見外放鑑定報告第69頁）。

５、狀況顯示器之具體功能與最終格式， 依約既應於PDR中由民航局、洛克希德公司及其次承包商三方共同研商確定，非民航局可單方任意提出，且民航局亦未於TACC PDR中提出約外要求， 則上訴人主張其得依闡明條款第4.1條調整完工期限，即非有據。又民航局既未提出非約外要求，且民航局業已提出顯示器格式資料，自無所謂闡明條款第

4.2條第1項第2款「政府提供之設備(GFE)未備供使用」、第4款 「未能依約及時完成於本契約下之任何其他義務」及第6款「超出民航局、美商洛克希德電子公司及/或其等所指定之要次承包商合理控制範圍外之事件所致之任何遲延」之可言，被上訴人主張就此部分其得依闡明條款第

4.2條第1項第2款、第4款、第6款展延完工期限，為無可取。

（）關於被上訴人主張「台北區域管制中心計畫控制顯示器之歸航資料顯示器」之約外需求部分（中科院鑑定報告第四大項第3小項）：

１、被上訴人主張TACC規格書第3.7.2節及3.7.3.2.3.2.3節規定，氣象資料顯示器之顯示內容應包含⑴氣象資料、⑵一般資料、⑶控制人員警示訊號，三種顯示內容，惟民航局於74年5月21日要求將上開顯示內容擴張並區分為獨立的四個警報區域及一個要求區域，且於各警報區域要求增TACC規格書未約定之顯示內容，並要求將部分訊號列為優先訊號等約外要求。雙方費時討論，洛克希德並因此耗費大量人力、時間，修改、變更顯示器相關韌體及軟體，延宕系爭航管系統之設計及開發。其得依闡明條款第4.1 條及第4.2條第1項第4、6款展延完工期限。

２、按TACC規格書第3.7.2節第1點關於計畫控制席部分規定「

1.Planning controller position: The following dis-play equipment and input/output equipment shall beprovided at the planning controller position: a.Information display module consisting of: (1)Meteorological information display;and（2)Aero-nautical information display. b.Flight tabulardisplay subsystems, consisting of: (1) Displaycontroller; (2) Insector talular display; (3) In-bond tabular display; (4) 2 interactive displays;

and (5) 1 keyboard.」，規定計畫控制席應具備「資料顯示器」及「飛航列表顯示器」二部分，其中「資料顯示器」子系統包含氣象資料顯示器及航空資料顯示器，「飛航列表顯示器」子系統則包含管制區內資訊列表顯示器、進入管制空域資訊列表顯示器，及互動顯示（見本院卷十七第625至626頁，TACC規格書第3-89、3-91頁），並於第

3.7.2.1.2節資料顯示器第5點規定「5.capaticy: Thedisplay shall be capable of storing and displaying

a minimum of 1,920 sybmols and 24 lines of data」，及於第3.7.2.1.3節飛航列表顯示器之3.7.2.1.3.2小節Tabular Display第5點規定「5.capaticy: The displayshall be capable of storing and displaying a mini-

mum of 80 sybmols per line and 48 lines ofdata」，規定資料顯示器至少能儲存並顯示1,920字元24 行資訊，飛航列表顯示器至少能儲存並顯示48行每行80個字元之資訊（見外放TACC規格書第3-95、3-99頁）。又洛克希德公司投標文件第二冊Engineering Section 1第2.2.1.2節「Tabular and Information Display」規定「Function-ally, each of the 25-inch displays pre- sents up

to 24 lines of information data and up to 48 lines

of tabular flight data (see figure 2-14). Thecapability for the controller to assign either themeteorological or aeronauticla informatiion dis-play to the upper or lower area of either physicaldisplay as well as locating the inbound and in-sector tabular displays is provided.」、「Thedisplay format consists of five major data andsub-data areas as shown: Flight Data:DepartureList, Information List, Enrout List - Postings,Alert - Left colum;Meteorological Data; RestrictedArea Informative Data; Controller Notices Data -GIMessage; Time Data」（見本院卷十六第269至270頁，洛克希德公司投標文件第二冊Engineering Section 1第2-4

3、2-50頁） ，將警報資訊規定於飛航資訊中，則被上訴人主張TACC系統「Inbound Tabular Display」 應顯示之資訊，包含警報等資訊在內，尚非無據。

３、又TACC規格書第3.7.2.1.2節第5點及第3.7.2.1.3.2節第5點雖規定資料顯示器至少能儲存並顯示24行資訊，飛航列表顯示器至少能儲存並顯示48行資訊，惟對於該24行及48行資訊之詳細內容並無具體規定，而依洛克希德公司投標文件第二冊Engineering Section 1第2.2.1.2節「Thefinal format of this display will also be final-ized at PDR」規定，資訊列表顯示器之最終格式定義，應於PDR中確定（見本院卷十六第270頁，外放洛克希德公司投標文件第二冊Engineering Section 1第2-50頁）。

又TACC PDR會議中民航局與洛克希德公司將涉及InboundInformation Display之顯示格式列為待辦事項第51號，將涉及Inbound Information Display 之控制人員警示訊號之處理方式列為待辦事項第52項，業據被上訴人陳明在卷（見本院卷十七第612至-613頁）。則民航局於74年5月21日PDR期間， 函送待辦事項第51號及52號之最終版本，及於所附待辦事項第52號版本， 說明資訊列表顯示器之Inbound information display關於警報(Alert)之相關資訊，應分為四大類別，並敘明各類別警報資訊之具體內涵等（見本院卷十七第639至649頁），即難認係約外要求。

上訴人主張民航局上開函件僅在重申基本需求規章之內容，提醒洛克希德公司納入設計，並非提出約外要求，應為可取。

４、此部分送經中科院鑑定結果，亦認「鑑定說明：所謂基本需求規章，應屬MIL-STD-1490規範中所定義的A規（System/segment specification)，其所作用為描述系統一般功能，該功能細部必須再進一步加以定義方能明確。根據本院發展軟體經驗，通常A規雖足由委託者訂定， 但若內容有任何描述不明確的地方，受委託者基於自身所承擔的風險，應盡力與委託者澄清。此鑑定項目係為顯示功能上的爭議，若洛克希德公司對到場資料顯示器中各種天氣資料及飛航資料格式分配及資料內容有任何疑義，應主動積極向民航局澄清， 最好在PDR進行前獲得一致的結果，如此方能進行細部設計工作。而非等到最後無法履約時，才作為推拖的藉口。附件一七三號資料顯示，需求規章第3.7.2節中有敘述計畫管制席位之資訊顯示器中， 須包含氣象資訊(Meterological)、飛航資訊(Aeronautical)。而飛航顯示次系統須包含(1)Display Controller, (2)Insector Tabular Display,(3)Inbound Tabular Dis-play,(4) 2 Interactive Display and (5)1 Keyboard。

而雙方依據基本需求規章對到場資料顯示器中各種天氣資料及飛航資料格式分配及資料內容等之細部設計，得由雙方討論協議顯示的方式。洛克希德公司在投標書第2-50頁中有說明「本系統之顯示功能在PDR時才作最後確認」(附件七十號），亦即說明本項顯示功能需求可改變，故民局對此項顯示功能的要求不屬約外要求。鑑定總結：依據上述鑑定說明，民航局要求歸航資料顯示區域應包含警報及民航局要求之資料，警報區域並再分為四個獨立邏輯顯示，應屬顯示細部功能，非屬約外需求」等語（見外放鑑定報告第69至70頁）。

５、民航局就部分既未提出非約外要求，被上訴人主張可依闡明條款第4.1條調整完工期限，為無可取。 又民航局既未提出非約外要求， 自無闡明條款第4.2條第1項第6款所定「任何超出民航局、美商洛克希德電子公司及／或其等所指定之要次承包商合理控制範圍外之事件所致之遲延」之情形。 又顯示器之最終格式定義，既於PDR時才作最後確認，民航局於與洛克希德公司研商後， 於PDR中提出飛航列表顯示器之最終格式定義， 亦難認有闡明條款第4.2條第1項第4項所定「未能依約及時完成於本契約下之任何其他義務」之情形。 被上訴人主張其可依闡明條款第4.2條第1項第4款、第6款展延完工期限，亦無可取。

（）關於被上訴人主張「緊急碼之擴充」之約外需求部分（中科院鑑定報告第四大項第4小項）：

１、被上訴人主張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日要求將緊急碼擴充為75XX、76XX及77XX，即擴充為7500至7599、7600至7699、7700至7799等300組編碼之約外要求， 洛克希德原已依規格書進行之韌體、軟體之設計，因此而需修改、變更，致影響系爭航管系統之設計及施作，其得依闡明條款第4.1條及第4.2條第1項第4款、第6款展延完工期限。

２、查TACC規格書第3.7.3.3.4.6.4.2.2節及TCC規格書第3.7.

3.3.4.4.4.2.2節之「Contents of Alphanumeric FullData Block」第1點，均規定「1.Field Z : Field Zshall consist of eitgt character positions con-taining alert messages. Alert messages includ thefollowing:Statement....Explanation: Emergency -controlled 7700 SSR return、Radio Off - controlled7600 SSR return、Hijack - controlled 7500 SSRreturn、Off the Airway...」 （見本院卷十七第704至706頁）。

３、又查洛克希德公司於74年7月22日提交一份說明緊急碼處理設計之文件「Emergency Code Target Consideration」予民航局（見本院卷十七第708至716頁），民航局則於74年8月5日函覆「CAA has reviewed the Ray AmesPaper of 85-07-01, which was attached to the sub-ject letter. In general,the approach outlined isacceptable to CAA. Our one commment relates to thefact that the emergeney codes are 75xx, 76xx and77xx; they are not restrict ed to 7500, 7600 and7700」（見本院卷十七第717頁），民航局既稱「theapproach outlined is acceptable to CAA.」 ，應已表示接受洛克希德公司之設計說明，其接續雖稱緊急碼亦可為75XX、76XX、77XX，不限於7500，7600及7700，但並未要求洛克希德公司進行修改。嗣民航局74年9月5日函文，就洛克希德公司TACC-1030設計文件之審閱意見中，固將緊急碼7500、7600、7700之設計，逕行塗改為75XX、76XX、77XX（見本院卷十七第731頁），惟洛克希德公司於收受民航局上開審閱意見後，並未表示民航局係提出約外要求，且嗣於75年3月22日提出之ATC-914設計文件中，將3組緊急碼擴充為7500至7577、7600至7677、7700至7777（見本院卷十七第742頁），則上訴人主張民航局僅係提醒洛克希德公司緊急碼並非侷限於7500、7600、7700，並未提出約外要求，尚堪信取。蓋若民航局所提為約外要求，依洛克希德公司於系爭航管自動化系統施作過程之作風，必定發函表示異議並主張民航局所提為約外要求；且洛克希德公司亦僅將緊急碼緊急碼擴充為7500至7577、7600至7677、7700至7777，而非擴充為7500至7599、7600至7699、7700至7799， 更足見民航局74年7月22日及74年9月5日函文，僅在係提醒洛克希德公司緊急碼非侷限於7500、76

00、7700，並非提出約外要求。

４、此部分送經中科院鑑定結果，亦認「鑑定說明：民航局於74年8月5日去函（LD-0000000）洛克希德公司(附件179號），表示請其考量緊急碼設計作法，將原有7500、7600、7700緊急碼擴充為75XX、76XX、77XX。但洛克希德公司接到此函後，對民航局所提新增需求一事，並無任何信函表達增加此項工作對其設計有何影響。以軟體發展工程觀之，此項需求增加對其設計及時程影響極小，判斷及顯示7500、7600、7700及75XX、76XX、77XX是一樣的動作，不會影到顯示器韌體，故並非如洛克希德公司所述因顯示器韌體須配合修改而延遲進度。 民航局是在PDR完成後才提出此考量事項，然本項緊急碼之擴充， 是CDR之前民航局以信件函請洛克希德公司考量(Considera- tion）納入，字面上並無強制性， 且洛克希德公司針對此項要求沒有任

何回應及反彈，所以此項要求並非屬於約外需求。鑑定總結：依據上述鑑定說明，本項緊急碼之擴充為民航局之補強建議，非強制要求，且顯示擴充碼之需求對洛克希德公司設計及時程影響極小，故本項目並非屬於約外要求，且不會導致顯示器韌體須配合修改而遲延進度」等語（見外放鑑定報告第71頁）。

５、民航局就此部分既未提出非約外要求，被上訴人主張可依闡明條款第4.1條調整完工期限，為無可取。又民航局既未提出非約外要求，自無闡明條款第4.2條第1項第6款所定「任何超出民航局、美商洛克希德電子公司及／或其等所指定之要次承包商合理控制範圍外之事件所致之遲延」之情形。被上訴人未據舉證，鑑定報告亦認此部分不會導致顯示器韌體須配合修改而遲延進度，亦難認有闡明條款第4.2條第1項第4項所定「未能依約及時完成於本契約下之任何其他義務」之情形。被上訴人主張其可依闡明條款第4.2條第1項第4款、第6款展延完工期限，亦無可取。

（）關於被上訴人主張「顯示字元組之定義之審核遲延及約外要求」部分（成大航太所鑑定報告第二大項第2小項）：

１、被上訴人主張系爭航管契約之GFE第18條C項規定民航局應於系爭航管契約訂立後2個月內（即73年2月20日前），透過顯示器設計會議，進行關於顯示器顯示字元組格式及內容之需求之討論，並於系爭航管契約訂立後3個月內(即73年3月20日前)定義、確定顯示字元組格式及內容之需求，民航局遲至73年3月6日至9日始舉行第1次顯示器設計會議，未如期於 73年3月20日前定義、確定顯示字元組格式及內容之需求，且於討論顯示字元組格式及內容之需求、及審核洛克希德關於顯示字元組之設計過程中，屢次提出逾越TACC規格書及TCC規格書所定64個子元組之約外要求 ，要求新增顯示子元組數量，其得依闡明條款第4.1條及第

4.2 條第1項第2、4、6款規定展延完工期限云云。

２、查TACC規格書第3.7.2.2.1.2.9.12.2節狀況顯示器控制台之「符號顯示需求(Symbol Display Requirements）」，及TCC規格書第3.7.2.2.1.2.10.12.2節狀況顯示器控制台之「符號顯示需求(Symymbol Display Requirements）」」均規定 「狀況顯示器控制台應能夠顯示如圖3-4所列或相當之符號；且應能容納符號字型之變更及額外符號之併入(a.The situation display console shall becapable of displaying the symbol set shown inFiguure 3-4, or its equivalent. b.The symbolgeneration design shall incorporate modularity toallow for changes to the symbol font and for theincorporation of additional symbols.)」（見本院卷十八第294至314頁，外放TACC規格書第3-125至3-134頁、TCC規格書第3-122至3-130頁）。 足見狀況顯示器之字元定義及顯示功能，並不限於TACC及TCC規格書表格3-4所列字元組，且需預留符號變更及額外符號之空間及需求。又TCC規格書第3.7.2.6.1.12.12節塔台數位顯示器之「符號顯示需求Symbol Display Requirements）」規定:「2.目錄:顯示器應能夠顯示26個大寫字母、數字0至9、以及至少19個特殊符號（2.Repertoire display shall be cap-able of displaying the 26 capital letters of thealphabet,the digits zero through nine, and atleast 19 specialsymbols.)」（見外放規格書第3-161頁），是塔臺數位顯示器之顯示符號，亦非僅以26個大寫字母、數字0至9及19個特殊符號為限。

３、被上訴人雖主張洛克希德公司於投標文件建議TACC及TCC系統之狀況顯示器及塔台數位顯示器之目錄至多可容納64個符號（A repertoire of up to 64 symbols is accom-modated)，民航局既已審閱並審定由洛克希德公司得標，應已確認狀況顯示器之規格至為僅多64個字元組云云。惟洛克希德公司於投標文件所載既僅為其建議，締約雙方既未就此修正TACC及TCC規格書上之需求， 被上訴人主張締約雙方已確認狀況顯示器之規格至多僅為64個字元組云云，應非可取。

４、又GFE第18條C項固規定民航局、洛克希德公司及其承商應於系爭航管契約訂立後2個月內， 透過顯示器設計會議，進行關於顯示器顯示字元組格式及內容之需求之討論，並於系爭航管契約訂立後3個月內定義、 確定顯示字元組格式及內容之需求（見本院卷十八第17頁）。另洛克希德公司於投標文件已表示狀況顯示器之最終格式應於PDR中定案（The final version og this layout will be re-viewed and finalized at Preliminary Design Review

（PDR））（見外放投標文件第二冊第2-50頁），是關於狀況顯示器之具體功能及最終格式，本待雙方於PDR中共同確定，則民航局於PDR中就狀況顯示器之功能及格式提出說明或澄清，應不屬約外要求。

５、況依75年8月19日「Draft-Minutes Notes」上「It wasagreed that a CAA approved set of nominally 140 (depending on the complevity of the characters)characters, symbols and ICONs for the TACC dis-plays and a similar set fot the TCC displays (in-cluding those in the Tower Cabs) will be provided

at no additional cost」之記載（見本院卷十八第317頁），及洛克希德公司76年2月12日函稱「The referencemeeting minuates - signed by the CAA on 27 Novem-

ber 1986 - contained an Agreement (Attach- ment4)by which Lockheed is to supply a minimum of 140characters in the TCDD character font,such char-acters to be subject to CAA approval. Lockheedhereby proposes, in the abssence of any futherinput form the CAA, and to minimice deliveryschedule impact, to direct its sub-contractor toprocess with the design of the TCDDs incorporating

the TACC character font. This character font pro-vides for up to 150 characters」 （見本院卷十八第319頁），足見締約雙方嗣已合意確定狀況顯示器之顯示字元組，至少為140個字元組，且不增加任何費用，被上訴人事後更提議將狀況顯示器之顯示字元組提高到可至150個字元組，上訴人主張狀況顯示器之顯示字元組之變動或增加，為系爭航管自動化系統之應具功能，非屬約外要求，應為可取。

６、而此部分經另案送請成大航太所鑑定結果，亦認系爭航管契約之約定可解釋為包括64字元以上之數量，且其結論更認為洛克希德公司既已接受民航局之要求，復未依約提出延長時程之要求，即應負擔100%之責任（見外放成大航太所補充鑑定報告第55頁）。被上訴人主張其得依闡明條款第4.1條、第4.2條第1項第2、4、6款規定，其得要求合理調整或逐日順延完工期限，應非可取。

（）關於被上訴人主張「民航局未提供空軍航管中心電腦介面連接之定義」部分 （成大航太所鑑定報告第三大項第5小項）：

１、被上訴人主張依GFE第12條b項之規定，民航局於簽約後應即提供初步之空軍戰管中心 （ADC）電腦訊息資料格式，並應於簽約後五個月內（即73年5月20日以前） 提供最終之空軍戰管中心電腦訊息資料格式，但民航局未依約提供，且將該等定義訊號位階規則之義務轉嫁予洛克希德公司，要求洛克希德公司提交CCITT X.25標準予民航局，並提出「將一位元組之閒置字元修改、變更為二位元」等約外要求，其得依闡明條款第4.1條、第4.2條第1項第2、4、6款規定調整或逐日順延完工期限。

２、按系爭航管契約之GFE第12條規定：「Item 12: DataFormats for Interface Planning: a...b.ADC computermessage formats.....f.....Date Required: Need pre-liminary data as soon after Contract Award Final 5MAC」，即民航局最遲應於簽約後5個月內提供空軍戰管中心電腦資料格式洛克希德公司（見本院卷十六第216頁）。而查，民航局已於73年1月18日提供空軍戰管中心電腦資料格式予洛克希德公司，並經洛克希德公司簽收在案，有經洛克希德公司簽收之證明文件在卷可稽（見本院卷十六第217至218頁）。73年3月9日顯示設計會議紀錄記載「

2.The existing ADC test and services messages wereforwarded to Lockheed (Mr.Joe Johnston) by the CAA(Ms.Jean Shen)...」（見本院卷十六第221頁），且締約雙方於74年8月8日第四次契約變更時，締約雙方亦再度確認GFE Item 12已由洛克希德公司收悉 （見本院卷廿一第313頁），民航局主張其已於73年3月3日以前將GFE第12條約定之文件，包括空軍戰管中心電腦資料格式全數交付洛克希德公司，應堪信取。 且GFE第12條「Data Formats

for Interface Planning」之「Date Required」:「Needpreliminary data as soon after Contract AwardFinal 5 MAC」 之規定，係指民航局最遲應於簽約後五個月內提供GFE第12條所列初步資料，而非最終版本， 已如前述（見五（）３），被上訴人主張上訴人未如期提供空軍戰管中心電腦訊息資料格式云云，應非事實。

３、又依契約介面控制文件第2.3節所定之通訊協定，原係CCITT V.10、CCITT V.24與CCITT V.26等標準（見外放介面控制文件第2-2、2-3頁、本院卷十四第179至181頁），嗣締約民航局於73年2月9日待辦事項會議中，同意洛克希德公司採用CCITT X.25標準（見本院卷十三第317頁），被上訴人欲採用介面控制文件所定標準以外之CCITT X.25標準，則民航局要求洛克希德公司提交CCITT X.25標準予民航局，自難認係約外要求。至於修改一位元之閒置字元為二位元部分，亦非約外要求，已如前述（詳見五（）５㈢）茲不再贅述。

４、此部分經另案送成大航太所鑑定結果，其鑑定結論為「本項不需鑑定」（見外放補充鑑定報告第71頁），亦難為有利於被上訴人認定。 被上訴人主張其得依闡明條款第4.1條、第4.2條第1項第2、4、6款規定調整或逐日順延完工期限，為無可取。

（）關於被上訴人主張「民航局未提供空軍航管系統介面連接測試支援」部分（成大航太所鑑定報告第三大項第6小項）：

１、被上訴人主張民航局違反系爭航管契約第四次修正之GFE第13d(4)項規定，未於75年2月至4月間備妥、提供並維持空軍戰管中心系統與TACC系統間之介面連接，致洛克希德無法進行TACC系統與戰管中心系統之介面測試工作，其得依闡明條款第4.2條第1項第2、6款規定，要求逐日順延完工期限。

２、查系爭航管契約第四次修正之GFE第13d項固規定「Item

(4)The CAA shallprovide and maintain end-to-endtermination of the digital communication data linkinterfaces between the TACC building and inter-facing systems(LRR, the ADC, FlSS), and the FlightService Stations at Chiang Kai-Shek Airport,Taipe1,Kaohsiung, Hualien and Makung. Time Required: 26-

28 MAC FEB-APR 1986.〔民航局應提供並維持臺北區域管制中心(TACC)建物與介面系統（長程雷達、空戰管中心及飛航資訊服務系統）及中正機場、高雄機場、馬公機場飛航服務站之間數位通訊資料連接介面之點對點之端點。需求時間：自系爭工程契約訂立後26至28個月，即75年2月4月間〕」 （見本院卷十八第185頁）。惟上訴人提供上開設施之目的，在驗證及測試上訴人建置之系爭航管自動化系統是否能符合契約要求、能否ADC系統相容並及時交換傳輸彼此之資料。 又空軍戰管中心ADC系統於系爭航管自動化系統招標時為已存在並運作中之系統，故系爭航管系統於涉及ADC之介面時，自應能與ADC系統相容，且能及時交換傳輸彼此之資料。且系爭契約空防介面控制文件第

1.2 節規定「This document definies the character-istics of the hardware, software and operationalelements that are necessary for the timely andefficient transfer of data between the TACC auto-mation system and the Air Defense System. The datatransfer includes the transmission of long radar

(LRR) data from the Air Defense Center (ADC) to

the TACC and the exchange of operational data in-cluding the flight data and the track data between

the TACC and the Air Defense Center.（本文件定義了TACC與戰管中心間及時、充分之資料傳輸所必須之軟體特性及操作諸元。 資料傳輸包含自ADC傳輸長程雷達資料至TACC，及飛行資料與航跡資料在內之操作資料交換」（見本院卷九第172至173頁，外放空防介面控制文件第1-1、1-2頁）。另TACC規格書第3.1.3.2節規定「The TACCshall be provided the capability to interface with

the ADC computer for the coordination and exchange

of flight and track data.（TACC系統應具備與ADC系統電腦交換介接之功能，以與ADC電腦相容並交換飛航資料與航跡資料）」 （見本院卷廿一第382頁，外放TACC規格書第3-12頁） ，亦可知解決TACC與ADC兩系統間相容性問題，為洛克希德公司之義務。

３、又契約空防介面控制文件第2.3節所定之通訊協定，原係CCITT V.10、CCITT V.24與CCITT V.26等標準（見外放介面控制文件第2-2、2-3頁、本院卷十四第179至181頁），嗣締約民航局於73年2月9日待辦事項會議中，同意洛克希德公司採用CCITT X.25標準 （見本院卷十三第317頁），惟中華民國空軍於 73年6月28日會議中表示TACC系統採用之 CCITT X.25之介面規則與ADC系統所使用之介面是相容（見本院卷十八第207頁） ，民航局及洛克希德公司乃於74年6月10日簽定「Singal Splitter /Preprocessor（雷達訊號分離器及前置處理器）」之契約文件，規定洛克希德公司應提供雷達訊號分離器及前置處理器，使TACC與ADC系統間具備相關資料之傳輸功能（見本院卷十八第323至324頁)，另洛克希德公司撰寫之設計文件ICD-001第1.3.3節亦載「The Singal Splitter/ /Preprocessor pro-vided by LILT will include the dedicated digitalcicurts to exchange the operational data betweenTACC and AACC.（洛克希德公司提供之雷達訊號分離器及前置處理器，包括交換TACC與AACC（即ADC）間操作資料之精密數位電路）」（見本院卷十八第327頁），亦足見TACC系統與ADC系統間之連接介面，應由洛克希德公司設計及建置，須洛克希德公司建置完成後，方能據以進行後續之系統測試。被上訴人主張民航局未能提供ADC電腦介面之連接測試支援，致本件工程遲延，應非可取。

４、被上訴人雖主張依測試原則第7.3.2條規定， 應以真實航跡進行TACC系統與ADC系統之相容性測試云云， 惟以模擬系統進行測試，可某種程度上免除以真實系統測試之相關變數及突發狀況，且洛克希德公司更能掌控測試之進行，降低測試不合格之風險，於洛克希德公司應屬有利。中科院之鑑定意見亦認「以軟體發展經驗法則觀之，發展過程中必須同步發展週邊介面模擬器來測試該發展係統，待真正驗收測試時再連接真實環境系統作測試。若買方同意以模擬器來執行驗收測試，對賣方而言將是求之不得，因為使用模擬器來執行驗收測試的風險將比連接真正的週邊系統來得低」（見外放鑑定報告第65至66頁）。而此部分經另案送成大航太所鑑定結果，其鑑定結論為「本項不需鑑定」（見外放補充鑑定報告第71頁），亦難為有利於被上訴人認定。被上訴人主張其得依闡明條款第4.1條、第4.2條第1項第2、6款規定調整或逐日順延完工期限，為無可取。

（）關於被上訴人主張 「民航局應提供GFE之設施之遲延及品質不良」部分 （成大航太所鑑定報告第三大項第7小項）：

１、被上訴人主張民航局依系爭契約第四次修正之GFE第2條至11條規定，應提供系爭航管工程各站建築物及場地，以供洛克希德公司安裝及測試系爭航管工程之各項系統及設備，並應提供電流、儀器接地網路、照明設備等硬體設施，且該場地及硬體設施應於系爭航管工程各設備開始安裝前完成， 惟民航局未依GFE第2條a項、第3條a項、第4條a項及第6條 、如期提供TACC系統、臺北TCC系統及高雄TCC系統之場地及硬體設施， 亦未如期提供TCC系統雷達資料抽讀器之場地及硬體設施，且其提供之場地及硬體設施品質不良，致延宕系爭航管工程之安裝及測試，其得依闡明條款第4.1條、第4.2條第1項第2、4、6款規定，要求合理調整或逐日順延完工期限。

２、查此部分於本院送請中科院鑑定時，被上訴人並未請求併送鑑定，而於另案送請成大航太所鑑定時，被上訴人就此部分亦未提出具體佐證，經成大航太所鑑定報告載明「控方所提之各項設施遲延及品質不良問題，並無具體佐證，無法鑑定」（見外放補充鑑定報告第71頁。）被上訴人遲至100年2月15日始具狀主張民航局未如期提供TACC系統、臺北TCC系統及高雄TCC系統之場地及硬體設施，亦未如期提供TCC系統雷達資料抽讀器之場地及硬體設施， 應認已逾時提出。

３、且查系爭契約第四次修正之GFE第2條「Building andgrounds with space for Taipei Area Contol Center（TACC）」之a點規定「Building to be complete to suit

CAA needs and permit contractor installation andtesting of all Area Control Center Automation Sys-tems:（1) AC power.(2)Instrument...(3)Lighting,...Date Required 21 MAC」（見本院卷十八第242頁），是民航局依上開規定固應於契約簽署後21個月即74年9月，提供TACC系統之場地既電力等供洛克希德公司進行系爭航管系統之安裝及測試。惟此係以被上訴人如期履行契約為前提之預估期程，故GFE第2條特別註記「Note:All in-stallations of the above items and other ancillarybuilding equipments.....must be complete beforestart of automation equipment installation.」（見本院卷十八第242頁），即該等設施於自動化設備安裝前完成即可，故民航局並不致僅因未於74年9月以前提供GFE第2條a點所列設備，即屬違反GFE之規定，並致系爭工程遲延。而依系爭契約第4次修正之時程表，TACC系統自動化設備安裝期程定於TACC系統CDR結束後二個月(見本院卷廿一第306頁），而TACC系統CDR於75年9月始結束，業據被上訴人陳明在卷（見本院卷十五第429頁），而依洛克希德公司75年10月7日函文內容可知，民航局於洛克希德發文前已提供GFE第2條a點所列之設備予洛克希德公司並無遲延（見本院卷十八第246頁）。又洛克希德公司上開函文固稱「Lockheed hereby informs the CAA that it

has temporarily stopped work at the TACC facility

due to the unsatisfactory electrical power supply- the CAA's electrical contractor havingapparently connected Taipei City power directly to

the equipment Technical power supply because of afailure of the Uninterruptbale Power Supply (UPS)system」，惟此僅係短暫之現象，且民航局之承商既已就不斷電系統之失誤採取補救措施，亦難認民航局所提供之設施品質不良。被上訴人以此主張民航局提供之設備不良致延宕系爭工程之安裝及測試，亦無可取。至於洛克希德公司固於75年10月15日提出改善TACC場地電力問題之建議方案（見本院卷十八第248至250頁） ，經民航局函覆「Lockheed should provide a detailed design so the

CAA can review its acceptability」等語（見本院卷十八第253頁） ，亦僅係對於洛克希德公司所提之建議案表示須待洛克希德公司提出詳細之設計方能評估，並未提出約外要求。

４、又依GFE第3條a點規定「Same as Item 2 above as re-quired for installation of the TCC Taipei automa-tion system。a.See 2a) for description.35MAC NOV86」，第4條a點規定「Same as Item 2 above as required

for installation of the TCC Automation System Kao-hsiung. a.See 2a)for description.41MAC MAY87」（見本院卷十八第243頁） ，則民航局本固應於簽約後35個月即75年11月提供GFE第3條a點規定之設施， 於簽約後41個月即 76年5月提供GFE第4條a點規定之設施，惟第2條Note部分之規定於此仍有適用， 故民航局僅須分別於台北TCC系統及高雄TCC自動化設備安裝前提供即可。 而依系爭契約第4次修正之時程表，TCC系統自動化設備安裝期程定於TCC系統CDR結束後6個月始進行（見本院卷廿一第308頁），而TCC軟體CDR於77年6月25日系爭契約經上訴人termi-nate時尚未完成，為被上訴人所不爭（見本院卷十五第667頁） ，則民航局縱未提供此部分之設施，亦不致遲延系爭工程之安裝及測試。被上訴人主張民航局未依限提供此部分設施致延宕系爭工程之安裝及測試，應無可取。

５、又GFE第6條a點規定「Space, power, and enviornmentalcontrols at the terminal short range radar site,Taipei for installation of the Radar.Data Extrac-

tor System. 35MAC NOV 86」 （見本院卷十八第244頁），依此民航局固應於簽約後35個月即75年11月提供安裝雷達資料抽讀器之空間、電力及環境控制等設施，惟TCC 系統雷達抽讀器之安裝，須待TCC軟體CDR結束後進行方有實益，且依系爭契約第4次修正之時程表，TCC系統自動化設備安裝期程定於TCC系統CDR結束後3個月始進行 （見本院卷廿一第308頁），然TCC軟體CDR於77年6月25日系爭契約經上訴人terminate時尚未完成，已如前述， 則民航局縱未提供此部分之設施，亦不致遲延系爭工程之安裝及測試。被上訴人主張民航局未依限提供此部分設施致延宕系爭工程之安裝及測試，應無可取。

６、綜上，民航局既未提出約外要求，亦無遲延提供GFE第2條a點規定之設施， 且TCC軟體CDR於上訴人terminiate系爭契約時尚未完成，民航局尚無須提出GFE第3條a點、第4條a點及第6條a點規定之設施， 其未提出於系爭工程之安裝及測試時程亦未生影響，則被上訴人主張其可依闡明條款第4.1條規定調整完工期限， 及依闡明條款第4.2條第1項第2、4、6款規定展延完工期限，自無可採。

（）關於被上訴人主張「塔臺飛航資料顯示器之分割螢幕」部分（成大航太所鑑定報告第四大項第1小項）：

１、被上訴人主張塔臺飛航資料顯示器（Tower Cab FlightData Display，以下稱TCFDD）係設置於各TCC系統之各機場控制塔台，用以顯示飛航資料資訊，屬機場控制塔台資料顯示子系統，依TCC規格書規定TCFDD中有關表格顯示（Tabular Display）及資訊顯示（Information Display）之容量均為1欄，每欄24行、每行80字元。 洛克希德公司於75年2月28日提出TCC-911之結構項目發展規格－塔臺飛航資料顯示器子系統文件予民航局審查，民航局已於75年5月8日函文同意洛克希德有關表格顯示及資訊顯示為每欄24行之設計，但遲延審核TCC- 911文件，且於76年1、2月間提出「塔台飛航資料顯示器分割螢幕」之約外要求，要求將TCFDD分為20行之資訊顯示區及28行之表格顯示 ，致延宕TCC系統相關軟體、硬體及韌體之設計開發工作 ，其得依闡明條款第4.1條、第4.2條第1項第2、3、4、6款規定調整或逐日順延完工期限。

２、查TCC規格書第3.7.2.6節「Tower Cab Flight Data Dis-play」之3.7.2.6.2.4「Tabular Display」第2點規定「2.Capacity.The tabular display shall be capable ofdisplaying a minumum of 80 symbols per line and 24line of data」，其3.7.2.6.2.3「Information Display」規定「The information display requirements areindentical to those for the Planning ControllerPosition specified in 3.7.2.1.2」，而3.7.2.1.2節第5點規定「5. Capacity.The display shall be capable

of storing and displaying a minimum of 1,920symbols and 24 lines of data.」 （見本院卷十九第19至22頁，TCC規格書第3-93、3-171頁），依此列表顯示器及資料顯示器應能容納至少24行，每行至少80個字元，被上訴人以民航局之要求超過24行每行80個字元，即屬約外要求，已無可取。且洛克希德公司投標文件第2冊Engi-neering Section 2-TCC第2.2.1.4節「Tower Cab FlightData Display」規定「....The keyboard functions andformat are similar to those decribed for the plan-ning Position（see paragraph 2.2.1.2)」，而2.2.1.2節規定「....The final version of this layout will

be reviewed and finalized at the PremliminaeryDesign Review(PDR)」（見本院卷十八第335至340頁，洛克希德公司投標文件第2冊Engineering Section 2-TCC第2-50、2-44、2-48頁）。是有關該顯示器之具體化作業需求，應由雙方於PDR中共同確定，則民航局於PDR會議中就TCFDD之顯示需求提出說明，即難認係提出約外需求。上訴人主張其於PDR會議中提出TCFDD功能性需求說明，不過係依軟體發展與雙方約定之流程，審核被上訴人之設計是否符合基本需求規章而已，並非提出約外需求，應為可取。

３、此部分經另案送請成大航太所鑑定結果，亦認「飛航管制自動系統為當時（1980年代）先進技術發展工程技術之一，基本合約規章下應對每一個技術細節有所說明，同時民航局也在基本合約規章中明定依據國際民航組織之技術規範為主要參考。所謂顯示器『分割螢幕』係指現今所稱之視窗技術，依據需求功能將單一螢幕分割成多個視窗，以便同時顯示不同的需求狀況。基本合約規章中沒有明確定義。視窗技術在1980年代已經大量使用在自動化系統中，國際間的航管自動化系統也已經將需求直接以視窗技術來表現。民航局於57項待決項目中，曾經提出顯示器螢幕分割的建議，洛克希德公司必須就技術專業面的需求，解決發展的問題。顯示螢幕分割之問題出在洛克希德公司之次合約商，若因此無法滿足需求，洛克希德公司仍應負擔技術發展的責任。1.鑑定結論：顯示器螢幕分割為基本合約規章所可以要求的範圍，不屬於約外要求。補充鑑定結論：本項所提補充證物不足改變或推翻原鑑定結論。」等語（見外放補充鑑定報告書第72頁）。

４、至於被上訴人主張民航局審核TCC-911文件遲延部分， 於本院送請中科院鑑定時，被上訴人並未請求併送鑑定，而於另案送請成大航太所鑑定時，被上訴人就此部分亦未主張，被上訴人於成大航太所及中科院鑑定完成後，遲至100年3月7日始具狀主張民航局審核TCC-911文件遲延，應認已逾時提出。 且被上訴人主張民航局審核TCC-911文件遲延，惟為上訴人所否認， 而民航局審核TCC-911文件有無遲延，事涉洛克希德提出之文件有無缺失？是否符合契約約定及系爭航管自動化控制系統之需求？是否完備可行？於正常情形下民航局所需之審核時期為何？等項，非僅憑兩造所提往來文件等所能判斷。且上訴人主張民航局並未遲延審核TCFDD之設計，且TCFDD之設計已經PDR定案，TCC-911文件雖係洛克希德公司次供應商Magnavox針對TCFDD所提出之硬體設備文件，TCFDD之設計既已PDR定案，TCC-911文件是否經上訴人審核已非要事等語 （見本院廿四第121頁），被上訴人主張民航局審核TCC-911文件遲延部分，尚屬無法證明。

５、此部分民航局既未提出約外要求，被上訴人又未據證明民航局審核TCC-911文件遲延致宕TCC系統相關軟體、硬體及韌體之設計開發工作， 則其主張其得依闡明條款第4.1條、第4.2條第1項第2、3、4、6款規定調整或逐日順延完工期限，自無可取。

（）關於被上訴人主張「塔臺數位顯示器之控制板」部分（成大航太所鑑定報告第四大項第2小項）：

１、被上訴人主張依TCC規格書第3.8.7.3節及附圖6-4等規定，機場控制塔台區域管制席位之塔臺數位顯示器（Tower

Cab Digital Display，簡稱TCDD）為1個，且係安裝在可於地面移動之操縱台。民航局於契約簽訂前之澄清會中，亦確認塔台數位顯示器為1個且係安裝在可於地面移動的操縱台。詎民航局竟於工程執行中，提出洛克希德應於中正機場塔台免費提供「具有雙顯示器之塔台數位顯示器」及包括控制板在內之二套塔台數位顯示器之輸入設備之約外要求，並要求塔台數位顯示器應安裝於塔台天花板滑輪軌道，致洛克希德須費時與民航局討論澄清，且於洛克希德與其承商Magnavox公司獲一致結論前，無法執行或繼續塔台數位顯示器相關軟體、硬體及韌體之設計開發，致系爭航管工程時程遲延，依闡明條款第4.1條、第4.2條第1項第2、3、4、6款規定，其得要求調整或逐日順延完工期限。

２、查TCC規格書第3.7.2.6.1.1節第2點規定「2.Faceplatefaltness. The radius of curvature of the innersurface of the cathode-ray tube faceplate shall be

a minimum of 343 centimeters (135 inches).」、第

3.7.2.6.1.2節第3點規定「3.Weight....If a separatedisplay head is used, its weight shall not exceed

34 kilograms (75 pounds)」、第3.7.2.6.1.13「RemoteControl Pannel」規定「The tower cab digital dis-play subsystem shall provide a remote controlpanel which will provide the controller with means

of selecting the functional pparameters available

in the display. A minimum of the control capabi-lity specified below shall be provided. 1.Center-Decenter. The capability shall be provided toselect/deselect either normal centered operation

or decentered mode of operation, and to control

the amount of off-centering....」（見本院卷十八第350至353頁，外放TCC規格書第3-152至3-153頁），準此，塔台數位顯示器TCDD之影像管內徑至少需達135英吋，重量不得超過75 磅，且在控制板上需具備center與decen- ter之選擇鍵。

３、又觀諸民航局75年10月3日致洛克希德公司之75年8月15日至19日TCDD審查會記錄摘要記載「During the 19 Augustmeeting, the display contractor once again statedthat the 135-inch radius of curvature requirementcould not be met for the TCDD and that a 90-inchcommercially available tube would have to be sub-stituted...In the 19 August meeting,discussionswere held on the remote control panel,(see item9,page 6). It was agreed that the 'Center' and'Decenter'functions would be moved from the remoteControl Panel to the Position Entry Device.Track-ball and that a Deviation/ Waiver Request would beissued by Lockheed to accommodate this chang...The

CAA requested that a Deviation/Waiver Request beprepared and submitted in obtain relief from thehead weight limit found in the TCC specification

if the weight can not be reduced to or below 75pounds...」（見本院卷十八第354至358頁），民航局76年4月27日函稱「...In reference 2), the CAA brought

to you attention that a letter report was to beprovided in accordance with item 11 of Reference3) in which the display contractor would discuss

his resons and rational for the selecting the 60-inch radius of curvature CRT,...On ECP NO.48 and

SCN NO.6, the paragraph cited for the change is

not appropriate....」（見本院卷十八第359頁），及民航局76年6月5日函稱「...Please provide replace-ment pages for the original (unrevised) pagesincluded with the subject EDPs. Upon receipt ofthese revised pages, the CAA will be able to pro-ceed with the approval of the subject document.Wewould also like to kown why it took form October16, 1986 till eraly May 1987 for the letter report

on the CRT radius of curvature to be forwardedfrom your Hsin Yi Road office to the CAA afterhous numerous requests for this information....」（見本院卷十八第362頁） ，上訴人主張因洛克希德公司提供之影像管內徑只60英吋，且TCDD之造遠端控制台不具備center與decenter之選擇鍵，重量亦無法低於75磅，不符合上開TCC規格書所載規格，洛克希德公司乃於75年8月19日之會議中提議變更設計，擬將控制板center與de-center選擇鍵功能移至軌跡球（Trackball）上操作，並就該項操作與TCDD之影像管內徑、重量等無法符合TCC規格書要求之項目，出具變更設計（Deviation/ Waiver），民航局要求洛克希德公司儘速說明相關期程，惟洛克希德公司遲至76年3、4月間才提出前揭項目之規格修改通知單，且因該通知單所附文件不夠週全，致民航局未通過關於TCDD之尺寸等方面之變更，之後被上訴人又拖至 76年5月才補提相關資料供民航局審核等情，應堪信實。塔台數位顯示器TCDD規格變更問題，既源於洛克希德公司無法依TCC規格書之需求履行，而由洛克希德公司提出變更設計之要求，自非可認係民航局提出約外要求。

４、此部分經另案送請成大航太所鑑定結果，亦以「控方所提塔台數位顯示器之控制板變更確實會造成洛克希德公司在工程設計及其製造上的延誤。辯方所提出附件156至163說明幾點變更的原因。 (a)洛克希德公司採用60吋顯示器代替規格所定的135吋顯示器，(b)部分規格無法滿足（例如Center及Decenter之操作），必須移至軌跡球操作， (c)顯示器重量超過規格。致使控制板的設計必須修改。根據辯方之附件資料，本項控制板之變更係洛克希德公司無法滿足各項規格細節所致，民航局同意其變更，並接受部分交換條件」等情，做成「控制板之變更出自於控方規格不符所衍生的問題，附件資料明確顯示雙方之協商及結論。本項顯示器控制板之變更屬於履行合約之範圍，不屬於約外要求」之鑑定結論（見外放補充鑑定報告第73頁）。

５、此部分民航局所提既非約外要求， 自無闡明條款第4.1條之適用，而洛克希德公司提議變更設計後，嗣又遲延提出變更設計相關文件，致TCDD之硬體變更設計懸而未決並延宕多時，亦難認有闡明條款第4.2條第1項第2、3、4、6款所定之宥恕事由。被上訴人主張其得依闡明條款第4.1 條、第4.2條第1項第2、3、4、6款規定調整或逐日順延完工期限，並無足取。

（）關於被上訴人主張「民航局擴充訊號表之約外要求」部分（成大航太所鑑定報告第四大項第4小項）：

１、被上訴人主張系爭契約闡明摘要（CAA Summary ofClarifications to the RFP Document）附表3-3 「訊號來源資格」，將TACC規格書中關於訊號來源資格加以修訂，明定TACC系統應與8項系統連接， 以交換70種訊號類型，民航局於工程執行中，一再要求擴增附表3-3， 致原訂之8項系統擴增為15項系統，70種訊號類型擴增為222種，其擴增部分均屬約外要求，且因雙方需費時澄清、協商，系爭工程因此延宕，其得依闡明條款第4.1條、第4.2條第1項第4、6款規定調整或逐日順延完工期限云云， 惟為上訴人所否認，辯稱民航局從未提出任何訊號表擴充之要求，係洛克希德公司能力不足，無法妥善處理TACC之系統控制、管理維修、離線研發支援作業及其與TCC、FISS、ADC等系統間之資訊傳遞功能，而衍生高達307個訊號類型，造成系統極端複雜而不易操作，被上訴人指摘上訴人提出訊號表擴充之約外需求，與事實不符等語。

２、查此部分於本院送請中科院鑑定時，被上訴人並未請求併送鑑定，而於另案送請成大航太所鑑定時，被上訴人就此部分亦未提出具體佐證，經成大航太所鑑定報告載明「控方與辯方對訊號表之擴充均無相關佐證，無法鑑定」（見外放補充鑑定報告第75頁。）被上訴人遲至100年3月7日始具狀提出資料主張，應認其相關資料已逾時提出。

３、且查TACC規格書第3.7.3.2.10.6節與TCC規格書第3.7.3.

2.8.5節均規定「The capability shall be provided

for positions to enter meesages types as defined

in Table 3-3」，而Table 3-3所列訊號類型之數量約為170個（見本院卷廿一第8至20頁，外放TACC規格書第3-237頁至3-242頁，TCC規格書第3-249頁至3-252頁） 。而民航局於 83年8月21日TACC PDR提出之手繪之TACC規格書附表3-3，就連接系統雖增加為11項（見本院卷十九第368至372頁），惟依83年8月21日TACC PDR備忘錄末段「Attachment's "E"through "J" were provided by the

CAA at the conclusion of the meeting for informa-tion purposes. Further discussion on these attach-ments are expected.」之記載(見本院卷十九第366至367頁），民航局應僅係提出意見，並未要求洛克希德公司必須納入設計，被上訴人復未證明洛克希德公司有據以納入設計。另民航局73年10月29日函文附件固載「PDR ActionItem 26....The TACC Specification Table 3-3, which

is attached, has been revised to ensure that eachmessage type can be input from more than ondivice. The table has also been extended toinclude some of the required message types thatwere not in the original version. However, thistable is still not complete, in the sense that itdoes not cotain all the system message type. Forexample, some of the message types that are dis-cussed in the response to PDR Action Item 61 are

not included.」（見本院卷十九第375頁），惟細繹其內容，雖稱TACC規格書附表3-3業經放寬， 但並無提出洛克希德公司必須納入設計之要求，且其信函本文並稱「Attached are the CAA comments on LILT's response

to PDR Action Item number 26.」 ，足見該函文及附件僅係對於洛克希德公司對於PDR待辦事項第26項回應之評論，被上訴人主張民航局提出擴充TACC附表3-3 之約外要求，尚屬無法證明。

４、被上訴人雖又主張民航局提出關於「使用中跑道（Runway

in use）」訊號，及要求新增代號TXT、ACK、MAK、AFN、

NOD、PID、RSA、RWA、WFC、WSA、REN及ERP第12種訊號類型之約外要求云云。惟使用中跑道為TACC規格書第3.7.3.

2.1.46節與TCC規格書第3.7.3.3.4.3.4.3節規定之功能性需求，非屬約外需求，已如前述（詳見五（）），則關於使用中跑道之顯示訊號，自不屬約外要求。且關於使用中跑道之TXT等12種訊號類型，業經列為PDR待辦事項第51項（AI 51），而洛克希德公司並於74年7月2日函稱「...riLockheed is pleased to advise the CAA that,although the proposed price of incorporating theagreed improvments is not insignificant, therewill be no impact on scheduled completion dates.」（見本院卷十六第185頁），被上訴人主張此部分為約外要求，且致工程遲延，亦無可取。

５、民航局既未提出約外要求，被上訴人亦未證明民航局有何未能依約及時完成之義務，或有何超出民航局、美商洛克希德電子公司及／或其等所指定之要次承包商合理控制範圍外之事件所致之遲延，則其主張其得依闡明條款第4.1條、第4.2條第1項第4、6款規定調整或逐日順延完工期限，即無足取。

（）關於被上訴人主張「民航局提出高層設計審核之約外要求」部分（成大航太所鑑定報告第四大項第7小項）：

１、被上訴人主張依SOW第5.3.3.1節及5.3.3.2節規定， 系爭工程之軟體設計審核， 應採用美國軍規MIL-STD-1521A之初期設計審核（PDR）及最後重要設計審核（CDR），另依闡明摘要之合約資料需求清冊（CDRL） 項目010規定，洛克希德公司所製作之軟體設計文件中，僅航空管理系統說明（ATC System Description，簡稱ATCSD） 應提供相關之高層設計說明予民航局審核，惟民航局於73年11月及75年7月間要求洛克希德公司於TACC之CDR及TCC之PDR開始前，就TACC系統、 顯示器韌體及TCC系統提供高層設計說明予民航局之約外要求， 致TACC之CDR及TCC之PDR遲延開始，因而延宕系爭工程之設計及執行，其得依闡明條款第4.1條、第4.2條第1項第4、6款規定調整或逐日順延完工期限。

２、SOW第5.3.3節固規定「All PDRs and CDRs shall beconducted in accordance with applicable CPCI sec-tions of MIL-STD-1521A」、第5.3.3.1節「PreliminaryDesign Reviews」規定「PDRs shall be conduted for

all CPCIs in accordance with MIL-STD-1521A, Appen-

dix C...」、第5.3.3.2節「Critical Design Reviews」規定「DRs shall beconduted for all CPCIs inaccordance with MIL-STD-1521A, Appen- dix D...」（見本院卷十九第465頁，外放SOW第5-8頁）」，惟MIL-STD-1521A乃美國軍方所撰寫之審查程序之一般性規範，非系統建置流程之規範。而TACC規格書第3.3.2.1節「Design

and Coding Requirement for Software」及TCC規格書第

3.3.2.1節「Design and Coding Requirement for Soft-ware」均規定:「...The design process shall be done

in top down fashion. This entails designing thecontrol architecture first along with interfactrequirements and data requirements.Subsequently,lower level functions are designed, and the pro-cess is continued until all required fucntions

and subfunctions, interfaces, and data require-ments have been designed. （設計流程應採由上而下之方式進行，首需依界面需求與數據需求進行控制結構之設計，其次再設計低階功並反覆實施至所有應具功能、子功能、界面及數據需求均設計完竣）」（見本院卷廿一第21至22頁、第388至390頁， 外放TACC規格書第3-66頁、TCC規格書第3-64、3- 65頁）。 洛克希德公司公司投標文件第二冊Engineering Section 1- TACC第3.7.1節規定「

The ATC System Description Document is a top-levelpresentation of the ATC system for the Republic ofChina.（ATC系統之說明將以高層展示之方式呈現）」（見本院卷廿一第25頁，外放洛克希德公司投標文件第二冊Engineering Section 1- TACC第3-142頁），另洛克希德公司投標文件第二冊Engineering Section 2- TCC第3.6.1節「LEC's Software Development Process」亦規定「System Requirement: The functions to be performed

by the system, including all hardware, software,

and firmware, have been set forth in thespecifica tion CAA-T-SS-002,REV 2....FunctionalSoftware Design: The software requirements aretrnaslated into a blueprint for implementationusing the concepts of top-down design and struc-tured programming.（系統需求：本件系統所應執行之功能，包含所有之硬體、軟體及韌體，業已規定於CAA-T-SS-002,REV 2（即TCC規格書）……功能軟體設計需求：系爭航管自動化系統軟體之建置方法，應採由上而下之設計概念及架構程式，以轉換軟體需求為可實行之藍圖）」（見本院卷廿一第393頁， 外放洛克希德公司投標文件第二冊Engineering Section 2- TCC第3-131頁） 。足見系爭航管自動化系統包含TACC及TCC系統之軟體與韌體， 均須先由洛克希德公司提出關於上層或高層結構之設計文件，經民航局核可後，方得據以續行低層功能設計。

３、則上訴人抗辯民航局於73年11月20日及26日去函洛克希德公司稱「2. The top-level desing for the systemmust be available, and the total system designmust demonstrate top-down structuring」、「...it

is not possible to review PDL documentation until:.. the top-dowm design has been reviewed andapporved;」（見本院卷十九第479、482頁），於74年12月23日函稱「CAA requires the Magnavox firmware'Top-Level-Design'」，於75年7月31日函稱「...(2)as

the initial phase of PDR,Lockheed should present a

TCC top-level design here in Taipei」 （見本院卷十九第487頁） ，函中提及系爭航管自動化系統須採高層設計（top-level design），且整體設計須能展現由上而下之架構等語，僅係重申系爭契約文件中關於系爭航管自動化系統之建置步驟，並非提出約外要求，應為可取。

４、此部分經另案送經成大航太所鑑定結果，亦以「飛航管制自動化系統牽涉到極大量的電腦軟體規劃設計，在系統發展過程中依基本規章所定義的採用『由上而下』的設計理念，因此高層設計的必要性極為重要。控方洛克希德公司之主張在合約中並無明訂必須採用高層設計，然而，依軟體開發是否能滿足整個系統的規格來考慮最為適切。辯方民航局所提附件174、175、176、177號證物，針對基本規章之條款說明，雙方合約中並無絕對的排斥性，乃依據實務的需要性來決定。 辯方所提附件178號證物確實顯示洛克希德公司經過協商瞭解後，於1985年11月26日簽署同意進行高層設計，已解決所發生的問題和困難」，而獲致「本項爭議契約基本規章中並無排斥性條款。雙方已經達成協議。本項不屬於約外要求」之鑑定結論（見外放補充鑑定報告第78頁）。

５、此部分既非約外要求，被上訴人亦未證明民航局有何未能依約及時完成之義務，或有何超出民航局、美商洛克希德電子公司及／或其等所指定之要次承包商合理控制範圍外之事件所致之遲延， 則其主張其得依闡明條款第4.1條、第4.2條第1項第4、6款規定調整或逐日順延完工期限，即無足取。

（）關於被上訴人主張「顯示器之待辦工作項目」部分（成大航太所鑑定報告第四大項第9小項）：

１、被上訴人主張民航局未依GFE第18條規定民航局於73年3月20日前提出顯示器格式定義，顯示器格式定義乃於TACC之PDR期間列為TACC PDR 待辦事項第13、36、51、52、61號及一般待辦事項第72號，嗣民航局於 73年10月至74年7月間提出之顯示器格式定義文件中，包含大量逾越基本需求規章之約外要求，致雙方進行多次之澄清及討論，嗣民航局終於承認其於待辦事項13、36、51、52、61及72號所提出者，為約外要求，並指示中信局於76年1月8日依闡明條款第4.1條及第4.3條提出變更指令，並辦理追加價款及延展時程。詎民航局雖承認係約外要求，並提出變更指令，但未就該等約外要求，辦理追加價款及延展時程。且於76年1月8日變更指令後，又提出新增之約外要求且未就此提出相應之變更指令，致相關之爭議，迄至 77年6月25日系爭契約終止時，猶未解決， 其得依闡明條款第4.1條、第

4.2條第1項第2款、第4款、第6款規定調整或逐日順延完工期限。

２、查GFE前言記載「The following is a listing itemsthat are to be furnished by CAA to support deve-lopment and implementation of the TACC and TCCAutomation」，並將「Display Format Definition」列為Item 18，且於「Date Required」記載「3MAC」，惟Item 18「Display Format Definition」項下亦載明「

Two months after contract award CAA, and LEC and

its display Subcontractor will convene a displayconference and define display formats to be deliv-ered to LEC by CAA」（見本院卷二十第24至35頁），狀況顯示器之格式定義，既係於簽約後由民航局、洛克希德公司及其次承包商共同召開會議研定後，再由民航局提交洛克希德公司， 顯然民航局依GFE第18條規定雖有提出狀況顯示器格式定義之義務，但該格式定義非由民航局單方決定提出，而係由三方研商決定後，再由民航局交予洛克希德公司執行。又洛克希德公司投標文件第二冊「Engi-neering Section 1」第2.2.1.2節「Tabular and Infor-mation Display」約定「The final version of thislayout will be reviewed and finalized at the Pre-liminary Design Review（PDR）」（見本院卷十四第64頁，外放洛克希德公司投標文件第二冊 EngineeringSection 1.2-50頁），上訴人主張狀況顯示器之具體功能與最終格式，依約應於PDR中由雙方共同研商確定， 尚非無據。而74年8月8日系爭契約第四次變更時，締約雙方已於契約變更附件3中GFE第18項之欄位記載「Received,Display Conference Completed MAR 1984」 （見本院卷廿一第319頁），上訴人主張民航局已如期提出GFE第18項之顯示器格式，尚非無據。

３、被上訴人雖又主張民航局於TACC PDR期間，於⑴待辦事項第13、36、51、52、61號及一般事項72號提出多項約外要求云云，惟此部分並非約外事項，業經敘明於五（）。另案送經成大航太所鑑定結果，亦認「本項控方所提之待辦事項目中，其次承商顯然即與民航局配合修改，控方所主張之約外要求顯然不符。本項目不屬於約外要求」等語（見外放補充鑑定報告第80頁）。民航局既未提出非約外要求，且民航局業已提出顯示器格式資料，自無闡明條款第4.2條第1項第2款「政府提供之設備(GFE)未備供使用」、第4款 「未能依約及時完成於本契約下之任何其他義務」及第6款「超出民航局、美商洛克希德電子公司及/或其等所指定之要次承包商合理控制範圍外之事件所致之任何遲延」之可言，被上訴人主張就此部分其得依闡明條款第

4.1條、第4.2條第1項第2款、第4款、第6款規定順延或展延完工期限，委無足取。

（）關於被上訴人主張「軟體標準及實施手冊（ATC-1200）之約外要求」部分（成大航太所鑑定報告第四大項第10小項）：

１、被上訴人主張闡明摘要之合約資料需求清冊（CDRL）項目010已明訂系爭系統工程之各種電腦程式結構項目發展規格，惟民航局於73年10月29日之CDRL 010重組計畫，要求洛克希德公司製作一額外之軟體標準及實施手冊（即ATC-1200文件），又於74年1月18日及1月29日片面擴張CPCI文件內容及格式，致洛克希德須與民航局反複澄清討論。民航局雖嗣於 74年3月20日函自認該ATC-1200文件係約外要求，惟仍要求洛克希德改寫CPCI文件，致洛克希德先前為備具關於CPCI文件已耗費之人力、資源及時程均成白費，並導致工程進度遲延，其得依闡明條款第4.2條第1項第4、6款規定展延完工期限。

２、查洛克希德公司投標文件第二冊Engineering Section 1-TACC第3.4.3.1節規定「TACC Operational ComputerProgram Software Documment.- The following areaswill be covered in this documentation:．Republic

of China Air Traffic Control System Description（ATCSD）.．Operational Computer Program Specifica-tions（OCPD）....．Program Design Specification（

PDS ）....Item ATCSD CDRL 010...OCPD CDRL 010...

PDS CDRL 010」（見本院卷廿一第44、45頁，外放洛克希德公司投標文件第二冊Engineering Section 1第3-132、3-133頁）。闡明摘要NUMBER:010，就ATCSD、OCPD、PDS亦均有記載，並於PDS部分載明「The PDS is a techni-

cal requirements document to assure that the in-tent of the CPFS is trnaslated into the ATC pro-gram design. This is a reviewed and approved priort- initiation of the actual programming effort.

The PDS identified each program within each func-tional area or subsystem, describes the allocation

of functions to each program, provides necessaryinterfact requirements, and identifies tables,items, and parameters to be used or set by eachprogram.」（見本院卷廿一第49至52頁），足見程式設計規格PDS（Program Design Specification） 文件，為應由洛克希德公司撰寫提出之文件，且為CDRL 010所定應由上訴人審核之文件，乃為確保電腦程式功能規格能轉換為系爭航管自動化系統之程式設計所需之技術文件，須經民航局審核後，方能據以進行後續之程式撰寫。上訴人主張PDS文件乃洛克希德公司依投標文件及CDRL 010所應提交民航局審核之文件，應為可取。

３、查洛克希德公司於74年10月29日函稱「In accordancewith the closure of the subject action item argeed

at the reference meeting, the enclosed document issubmitted for your review and comment as soon aspossible.」，其所附CDRL 010 RESTRUCTURING載：「1.Durinig the Preliminary Design Review (PRD) anAction Item was generated to review the structure

of the documentation submitted for CDRL 010 andrevise that structure to improve presentation andtraceability of the documentation.Several splintertroup meetings were held in which the subject wasdiscussed.Abasic guideline within these meetings

was to improve the usefulness of the documentation

by renumbering and rearranging certain portions of

a documents while maintaining the basic textualinformation.Documentation was not to be rewrittenjust to accommodate restructuring....4.Renumbering

Scheme for CDRL 010: The renumbering scheme forCDRL 010 documentation is shown in Table 1.」，其table載「NEW ATC-1200 OLD（part of PDS) SoftwareDevelopment Standard」（見本院卷廿一第55至58頁），洛克希德公司既於重組CDRL 010文件時，將屬於CDRL 010中PDS文件一部之軟體發展標準（Software DevelopmentStandard）重新編號為ATC-1200文件，則ATC-1200文件自屬PDS文件之一部分，為洛克希德公司依投標文件及CDRL010所應提出之文件，被上訴人主張此部分為民航局所提約外要求，應非可取。

４、又系爭航管自動化系統之軟體開發，依系爭契約工作說明書SOW及投標文件之相關記載，必須採取由上而下之方式進行設計，在建置過程中，則需先分析買受人之需求，並將之轉換、落實至為具體之設計作為（下稱「分析與設計階段」）。在「分析與設計階段」中，出賣人須根據專案之性質、規模、成本、時間及人員素質等因素，斟酌採取合宜之「方法論」（Methology） ，以作為主要之工作技術指引，使系統開發工作更有效率，而兼顧品質保障與風險降低等基本要求。而方法論中，又區分為所謂「正規之方法論」與「半正規之方法論」，後者尚可進一步區分為「實體關係模型」（ERM）及「物件導向方法論」（Object-Oriented Methology，下稱OOM） ，而OOM方法論經演進後，又陸續出現Yourdon Methology（優頓方法論）等類之方法論，惟沒有任何一個方法論可適用於所有軟體開發之情形，故出賣人須在審視專案性質、規模、成本、時間及人員素質等因素後，決定採用何種方法論以進行系統建置、軟體開發及設計文件之撰擬，並接受買受人之審核，以確保所建置之系統真能符合買受人之需求（見本院卷廿一第394至407頁，林錦陽著「軟體工程－物件導向程式設計與UML系統分析實作」第七章）。

５、被上訴人主張民航局於 74年1月18日函文要求擴充ATC-1200文件，惟為上訴人所否認。查民航局74年1月18日函稱「CAA has reviewedthe documentation standard for

the Computer Program Design Specification(Apprendix B of ATC-1200) and found it to requireadditonal information. The primary problems is thereliance on the documentation of the Yourdonmethodology, which CAA finds to be insufficient tosatisfy all of its needs.CAA has no objection toLILT using the Yourdon methodology and its docu-mentation for its internal activities, but insiststhat the delivered documentation satisfy CAA'sneeds....In the interest of speeding the resolu-tion of this issues, CAA has modified and extended

the CPDS standard...」（見本院卷209至210頁），上訴人主張CDRL 010經重組後，洛克希德公司於73年提交ATC-1200 文件供民航局審閱時，註明將以OOM方法論中之「優頓方法論」為系爭航管自動化系統之工作技術指引，惟優頓方法論是否完全適宜作為建置系爭系統之方法論，未經洛克希德公司證明，為免延誤交期，乃於 74年1月18日去函說明洛克希德公司若擬採取優頓方法論，仍須提供額外之資訊以供審核，且民航局亦將相應緩和並放寬審核之標準，期能補救因被上訴人能力不足所致之遲延，非提出約外要求，應為可取。

６、又被上訴人雖主張民航局已於74年3月20日函自認ATC-1200文件為約外要求云云，惟為上訴人所否認，查民航局74年3月20日函稱「1.The ATC-1200 document is not acontractual requirement. That is true. However,documenting the information, that CAA suggestsshould be in ATC-1200,is a contractual requirement....3.The Yourdon design documentation satisfieis

the contractual requirements. This is not true.

The Yourdon documentation provides an incomplete

and unclear definition of the program desings. Itsatisfies neither CAA's proposed CPDS outlines norLILT's 'brief description' for the CPDS (provided

by LEC as a replacement for the CRDL-10 DID, andincluded in the contract).As such, it is nuaccept-able」（見本院卷二十第229至230頁），細繹其函文內容，係表示被上訴人依優頓方法論撰寫之ATC-1200文件，並非契約需求，但依民航局建議方法撰寫及提出ATC-1200文件，則為契約之需求；並表示所謂以優頓方法論撰寫設計文件，可滿足契約需求之說法，並不正確。因為優頓方法論在程式設計上之定義，具有不完整且不明確之缺陷，其既不能滿足民航局之CPDS標準，亦不能滿足洛克希德公司對CPDS之摘要說明，核無承認ATC-1200文件亦屬約外要求，被上訴人主張民航局已於74年3月20日函自認ATC-1200文件為約外要求云云，委無足取。

７、此部分經另案送請成大航太所鑑定結果，亦認「飛航管制自動化系統主合約基本規章依慣例必須完成軟硬體之說明文件。計畫完成之驗收程序中，所發展之軟硬體說明文件為必須的條件……鑑定結論：…依據基本合約規章，本系統應繳付之必要文件應包括軟體說明…本項不屬於約外要求」（見外放補充鑑定報告第81頁）。此部分民航局既未提出非約外要求，自無闡明條款第4.2 條第1項第6款「超出民航局、美商洛克希德電子公司及／或其等所指定之要次承包商合理控制範圍外之事件所致之任何遲延」之可言，且民航局未能核可洛克希德公司提交之ATC-1200文件，係因洛克希德公司所採用之方法論有缺陷不能滿足CPDS標準所致，亦難認有闡明條款第4.2條第1項第4款之情形，被上訴人主張就此部分其得依闡明條款第4.2條第1項第4款、第6款規定展延完工期限，並無足取。

（）關於被上訴人主張「臺北區域管制中心及終端區域管制中心軟體結構說明之約外要求」部分（成大航太所鑑定報告第四大項第11小項）：

１、被上訴人主張系爭契約闡明摘要之合約資料需求清冊CDRL010已明定系爭工程之各種電腦程式結構項目發展規格（CPCI文件），該CPCI文件中之總體電腦程式說明（OCPD）係就電腦軟體之功能，提供總體、概觀說明。民航局於73年10月29日之CDRL 010重組計畫中，提出變更總體電腦程式說明（OCPD）文件之位階之約外要求，復於 74年6月10日函文捨棄新CDRL 010之總體電腦程式說明，要求變更為提供高層軟體設計說明即軟體文件結構說明，置於TACC-2000文件之約外要求，其得依闡明條款第4.1條、第4.2 條第1項第4、6款規定調整或逐日順延完工期限。

２、查洛克希德公司投標文件第二冊Engineering Section 1-TACC第3.4.3.1節、及Section 2 -TCC第3.4.3.1節均規定「Operational Computer Program Specifications（OCPD

）」文件為洛克希德公司提供之「TACC OperationalComputer Program Software Document」及「TCC Opera-tional Computer Program Software Document」所應包含之文件，列屬CDRL 010文件內容。並於Section 1-TACC第3.7.2節及Section 2- TCC第3.7.1節規定「The OCPDserves to identify, in general terms, the func-tions of the overall computer program includingdescriptions of system functional capability,equipment configuaration and variations, eachfunction area, and each version and its implement-ation plan」，是其內容包括系爭航管自動化系統之功能性能力、設備組態與變異及各功能區域等之描述（見本院卷廿一第44至47頁、第66至72頁，外放洛克希德公司投標文件第二冊Engineering Section 1-TACC第3-132、3-133、3-142頁、Section 2-TCC第3-127、3-129、3-137、3-138頁），依闡明摘要規定，並為應提交民航局審核之文件（見本院卷廿一第50頁）。又洛克希德公司於73年10月29日函說明重組CDRL 010文件將OPCD文件重新編為TACC-2000及TCC-2000（見本院卷廿第293至303頁），則TACC-2000與TCC-2000仍為洛克希德公司依投標文件及CDRL 010所應提出之軟體設計文件。

３、CDRL 010文件既為契約明定之文件，且系爭航管自動化系統之顯示器等事項之功能與最終格式，依約應於PDR中由雙方共同研商確定，已如前述，則依實際需要之調整CDRL010文件位階，應非屬約外需求。且73年7月20日雙方就重組CDRL 010文件之TACC PDR待辦事項第1項會議後 （見本院卷廿第291頁），洛克希德公司未曾主張此為約外要求，並隨即於73年10月29日提出重組計劃（見本院卷廿第

293 至303頁），被上訴人主張此為約外需求，應非可取。

４、被上訴人雖又以民航局 74年6月10日函表示OCPD已無存在必要，片面要求捨棄，變更為新的高層軟體設計說明之約外要求云云。查民航局於74年6月10日函稱「Ath thePlainfield meeting it was agreed that the COPD andSPOD documents would be evaluated to determine theneed fot their publication. As has discussed.CAAfeels that the 'NAS-like' OCPD documents are oflimited value,and therefore have no meaning forexistence; but there is a definite need to haveintroductory top-level software design information

in some convenient form. Rather than a repeat thisinformation in several documents. We have sug-gested that it be published once - probably asTACC-2000 and SUPD-2000 - and referred to by theother document.In order to facilitate the resolu-tion of this issue, CAA has prepared 'strawmen'definitions of possible TACC and SUPD design in-troductions, which are attached.」 （見本院卷廿第305頁），細繹其內容，是就雙方於平原市之會議時同意評估OCPD與SUPD文件是否published一事，表示雖然OCPD文件價值有限，但高層軟體設計資訊之介紹仍有必要，民航局建議與其將此資訊一再重覆於數文件中，不如僅適宜的published一次，而其他文件則逕以援用， 並檢附說明範例，並無要求洛克希德公司廢棄OCPD，亦非提出約外要求。且軟體高層結構設計文件，為洛克希德公司應提出之文件，已如前述（見五（）），被上訴人主張民航局要求捨棄OCPD另提出新的約外要求，應非可取。

５、此部分經另案送請成大航太所鑑定結果，亦認「CDRL 010既為合約規章中所明訂之必要文件，其中編整與修訂可以依據實務需求調整。本項不屬於約外要求」等語（見外放補充鑑定報告第82頁）。此部分民航局既未提出非約外要求，自無闡明條款第4.1條之適用，亦無闡明條款第4.2條第1項第6款「超出民航局、美商洛克希德電子公司及／或其等所指定之要次承包商合理控制範圍外之事件所致之任何遲延」之情形，且民航局既未提出約外要求，自無提出變更指令之義務， 亦難認有闡明條款第4.2條第1項第4款之情形，被上訴人主張就此部分其得依闡明條款第4.2條第1項第4款、第6款規定展延完工期限，並無足取。

（）關於被上訴人主張「飛航計畫之數目」部分（成大航太所鑑定報告第四大項第12小項）：

１、被上訴人主張TACC規格書第3.2.1.1節第8項規定，飛航資料處理系統每小時應能接受及處理至少300個飛航計畫 ，並未規定該等飛航計畫須限於「動態」，民航局於工程執行中， 要求飛航資料處理系統每小時應能接受及處理300個動態飛航計畫，應屬約外要求， 其得依闡明條款第4.1條、第4.2條第1項第4款、第6款規定，要求合理調整或逐日順延完工期限。

２、查所謂「飛航計畫」 （Flight Plan），依洛克希德公司提出之ATC-1000文件之定義「A collection of datarelating to a specified aircraft or formation ofaircraft containing for tracking and producingFDEs used to control the flight」（見本院卷廿第337頁），係指有關特定航機之資料，包括航跡、飛行數據等控制飛機所必需之資料，亦即特定航機向飛航服務單位提供關於航空器擬飛航或部份飛航之特定資料。又在實施航空管制之過程中，關於即將或已經成為航管單位掌握之飛航器資料即為動態（Active）之飛航計畫（如：起飛、鄰區交管或空中申請之飛行計畫），須能由系爭航管自動化系統之資料庫中提出或進行相關處理，以核實進行航管措施等情，已據上訴人所陳明。

３、又查TACC規格書第3.2.1.1節「System Capability andAccuracy Requirements（系統功能及準確性需求）」第1項規定「The TACC Automation system will meet thecapacity and accuracy requirements specified below....8.The system shall be capable of accepting andprocessing a minimum of 300 flight plans in anhour, and ten flight plans in a peak minute. 9.Thesystem shall be capable of storing a minumim of1500 repetitive flight plans and 300 nonrepetitiveflight plans, simultaneously.」 （見本院卷廿一第75頁，外放TACC規格書第3-24頁）。依此，系爭航管自動化系統應能於1小時內接收並處理至少300筆飛航計畫，尖峰時刻1分鐘接收並處理至少10筆飛航計畫， 並應能同時儲存至少1,500筆固定飛航計畫及300筆非固定飛航計畫，以確保上訴人能事前知悉航空器之相關飛航資料，並據該等儲存於資料庫中之飛航計畫資料，預先制訂、調整、修正或實施相關航空管制措施。 上開第8項就系爭航管自動化系統應能於1小時及尖峰時刻1分鐘內接收並處理飛航計畫數量之規定，雖未載明為動態飛航計畫，惟非即將或已經成為航管單位掌握之飛航器資料，即非屬動態飛航計畫者，既尚無需處理實施相關航空管制措施，並參諸第9項規定，非屬動態飛航計畫者，自不在上開第8項規定之列。被上訴人主張TACC規格書第3.2.1.1節第8項規定之飛航數量，兼指動態及非動態之飛航計畫，容有誤會。其主張民航局要求飛航資料處理系統每小時應能接受及處理300 個動態飛航計畫，為屬約外要求，應無可取。

４、此部分經另案送請成大航太所鑑定結果，亦以「基本規章中明訂本系統能接受與處理（Processing） 至少300飛航計畫，以及儲存（Storing） 至少1500個固定的飛航計畫資料及300個非固定飛航計畫之資料。 依據飛航管制系統之結構，處理中（Processing）之飛航計畫即為動態飛航計畫（active flight plan）之一部分。所有非動態之飛航計畫全部進入儲存的空間中， 即為後數之1500及300飛航計畫」等情，而得出「本項所稱之動態飛航計畫即為進行處理中之飛航計畫。控方之主張不符，本項不屬於約外要求」（見外放補充鑑定報告第83頁）。此部分民航局所提既非約外要求，自無闡明條款第4.1條之適用，亦無闡明條款第4.2條第1項第6款「超出民航局、美商洛克希德電子公司及／或其等所指定之要次承包商合理控制範圍外之事件所致之任何遲延」之情形，且民航局既未提出約外要求，自無提出變更指令之義務，亦難認有闡明條款第

4.2 條第1項第4款之情形，被上訴人主張就此部分其得依闡明條款第4.2條第1項第4款、第6款規定展延完工期限，並無足取。

（）綜上，上訴人既未提出約外要求，洛克希德公司復無闡明條款第4.2條第1項所定可宥恕之情形，則被上訴人主張其得依闡明條款第4.1條規定合理調整完工期限， 及依闡明條款第4.2條第1項各款規定順延完工期限，即非有據。

六、洛克希德公司履行系爭契約有無遲延？

（一）查系爭航管自動化契約於簽訂後， 迭經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日 （見原審原證卷一第7至55頁），惟迄至76年11月30日，洛克希德公司並未完成上開任何一項系統，亦未交付TACC系統，為兩造所不爭。而上訴人於系爭契約執行中，並無提出約外要求，被上訴人亦無闡明條款第4.2條第1項各款所規定之可宥恕情形，已如前述，則上訴人主張洛克希德公司履行系爭契約遲延，尚非無據。

（二）被上訴人雖抗辯依洛克希德公司所提完工計畫，預估系爭航管自動化系統尚須39個月工期始能完工，故整體工程之完工期限應調整延展至80年9月25日，而依成大航太所鑑定報告，民航局應負擔45.38%之遲延責任，故TACC系統之完工期限應延至78年4月10日，TCC台北系統完工期限應延至78年9月10日云云。惟洛克希德公司所提完工計畫並非適當之補救計畫（詳後述），且依闡明條款第5.3.1.a.之第2款「If LEC fails to preform any of the otherprovisions of this contract, or so fails to makeprogress as to endanger performance of this con-tract in accordance with its terms, and in either

of these two circumstances does not take appor-proate action to cure such failure within...」之規定，補救計畫係為補救洛克希德公司無法履行契約約定條款，或無所進展而危及契約條款之履行之情形之計畫，係就已遲延之工程提出補救措施，其所需工期，並非即屬過去履行契約期間因雙方責任所致遲延之期間，自不能以之計算因民航局遲延責任所展延之工期。被上訴人以此主張TACC系統之完工期限應延至78年4月10日，TCC台北系統完工期限應延至78年9月10日，洛克希德公司並無遲延，應無可取。

（三）又中科院之鑑定報告雖認民航局於洛克希德公司履行契約產生問題時，未善用履行爭議解決之機制妥善解決爭議（

54 ），未即時明確處置，導致雙方認知差異，應就系爭契約之遲延依雙方負擔之加權責任百分比負13.4之責任（見外放鑑定報告2頁）。惟TACC系統應完工期限為76年8月30日，算至76年11月30日已遲延3個月，依中科院鑑定報告民航局應負擔之13.4%責任計算，民航局應負擔之遲延天數為12天（90×13.4%＝12，小數點以下四捨五入），則加計民航局應負擔遲延責任之天數後，洛克希德公司亦應於76年9月12日完成TACC系統，惟其迄至96年11月30日仍未完成，自已遲延。縱以成大航太所鑑定報告認定民航局之過失責任45.38%計算，民航局應負遲延天數為為40天（90 ×45.38%＝40，小數點以下四捨五入），洛克希德公司亦應於76年10月10日完成TACC系統，惟其迄至96年11月30日仍未完成，亦已遲延。

七、洛克希德飛機公司提出之完工計畫是否可認已就契約之履行為適當之補救？

（一）查中信局於76年12月1日去函洛克希德公司， 以簽約起已歷經47個月，洛克希德公司從未交付任何關於該系統之產品，系爭航管自動化系統顯無法如期履行，催告洛克希德公司如未能於收到通知後60日內採取積極有效之補救計畫，修補治癒上開違約情形，將依闡明條款第5.3.1條TERM-INATE系爭契約，有該信函在卷可稽 （見原審原證卷一第59頁） ，洛克希德公司雖嗣於77年1月15日提出完工計畫（見本院卷十一第156至263頁）。惟依洛克希德公司所提之完工計畫，完成TACC系統尚須27個月， 完成TCC系統及完次航管系統尚須37個月， 並另需額外2個月移除舊航管系統硬體並遷移新硬體於TCC-1， 共需展延交期達39個月（見本院卷十一第212頁背面、第261頁），並需追加價金美金1924萬2943元，有洛克希德公司 77年2月12日函在卷可稽（見原審卷二第89頁）。

（二）又查系爭航管自動化契約係於72年12月20日簽立，嗣於第四次修正時，將整體完工期間修正為77年5月30日 （見原審原證卷一第37頁），工程期間計53個月又12日，而洛克希德公司所提系爭完工計畫，完成系爭航管自動化系統之整體工程共需展延工程期間39個月，高達原定工程期之

73.58%，為原已進行之工期（72年12月20日至76年11月30日） 之82.1%，幾近於增加一個原有工期。另系爭契約經76年9月第六次修正後， 其金額計為美金3,166萬7,184元及新台幣2億9,684 萬5,974元，有第六次契約修正書在卷足憑（見原審原證卷一第11頁），依76年新台幣兌換美金匯率31.17比1計算（見本院卷二十四第304頁） ，新台幣2億9,684萬5,974元之契約價金折合美金9,523,451元，則依此計算，系爭契約經第六次修正後其價金共計為美金4,119萬935元（31,667,184＋9,523,451＝41,190,935），而依洛克希德所提完工計畫，完成系爭航管自動化系統之整體工程，需追加價金美金1924萬2943元，高達原契約價金之46.72%，將近原契約金額之半數。準此，依系爭完工計畫所需展延之工程期間及追加之價金之形式上觀之，已難認係適當之補救計畫。

（三）關於完工計畫之內容，被上訴人雖主張洛克希德飛機公司提出之完工計畫，內容完整詳盡，民航局就系爭航管工程所聘任之技術顧問邁特公司亦認該完工計畫良好可行，應為履行系爭契約適當之補救措施云云，惟為上訴人所否認。 查邁特公司於1988年1月27日提出第一份評估報告之函文固稱「……We find the plan to be technicallysoud and recommend it be used for agreement andnegotiation with Lockheed to continue the effort.There are flaws in the plan but it is believedthat CAA/MITRE working closely with Lockheed canresolve these issues and reach agreement. Theattachment to this letter privdes commnets andrecommendations for resolving the important flaws

in the plan.....（我們認為此一計劃在技術上健全，良好可行，故建議民航局藉此達成協議，並用以與洛克希德商討繼續努力。雖然計畫內有若干瑕疵，但相信在民航局／邁特公司與洛克希德公司密切合作下，將能化解上述問題達成協議。隨信附件之評論及建議是為了解決計劃中重要的瑕疵…）1.Lockheed appears to understand theproblem.Their identification of problem areas to

be examined and their work over the past fewmonths reflects a recognition of where the diffi-culties are.（1.洛克希德了解問題之所在。他們認定問題之範圍必須被檢驗，他們過去數月的努力反映出對於困難所在的認知）2.Lockheed understands the necessarycourse of action needed to deal with the problemareas.Their recommended approach is sound. Thespecific nature of problems and their soulationswiil be identifed over the nexst months if thecourse of action precribed by the plan is followed（2.洛克希德了解處理問題所必須採取之必要行動。他們所建議之方法健全良好，問題的本質及他們的解決方案，如計畫付諸實施，將於之後的數月內確認） 3.Theschedule presented by Lockheed is reasonable tocomplete the course of action prescribed by theplan with the additional planned manpower（3.洛克希德所提出的時程合理，如有計畫所定之額外人力，應能按計畫內所敘述之程序完成該工程）....MITRE canstate that the Lockheed "Project Completion Plan"

is a sound plan and, if executed by Lockheed willcomplete the air traffic control modernizationprogram sucessfully.（邁特公司認為洛克希德之完工計畫為良好之計畫，且如由洛克希德執行，應能成功地完成航管自動化系統）MITRE has considered the Lockheed"Project Completion Plan" with the other alterna-tive in mind. MITRE concludes that continuing with

the Lockheed effort based on their plan is thebest approach because in our judgment,this is:（邁特公司評估洛克希德之完工計畫時，曾一併考量其他替代方案。邁特公司之結論為由洛克希德依據他們所提計畫繼續施工，將是最佳途徑，蓋：）1.the quickest way ofcompleting the Automation Program,2. the latestcostly way of completing the Automation Program,3.

the least effort approach, and 4. the best way ofgetting the system that has been designed over

the past four years.（1.完成自動化系統最快速之途徑。2.完成自動化系統費用最低廉之途徑。3.最省力之途徑

4.獲得完成歷經4年設計完成之系統之最佳途徑）We alsofeel that continuing with Lockheed may be themost straight-forward, least troublesome and leastdistasteful way of completingthe program.however

you and your staff may be better able to judgethis. Our conclusion and recommendations are based

on the technical merits of the "Project CompletionPlan" We recoginze that there are still businessissue to be resolved and that contract changeswill have to be made so the effort can continue.…（邁特公司並認為與洛克希德繼續進行工程，乃屬最直接、窒礙最少，以及困擾最小之方式，以完成本工程。然而，可能您與您的團隊就此更能判斷。我們的結論與建議是基於技術層面對完工計劃為評估，我們承認仍有商業上之議題尚待解決，契約也需變更……）」等語（見原審被證卷第一冊第38至39頁、第本院卷廿一第243至244頁），雖稱系爭計畫在技術上健全良好可行，但亦表示僅係基於技術層面所為評估，並稱尚有商業上之議題尚待解決，並表明對於完工計畫之重要瑕疵之評論及建議載於附件。

（四）而其於附件記載：「There are areas within the Planthat should be discussed with Lockheed to clarifytheir intent, to minimize CAA concern, and toresolve disagreement....However, the followingareaare of major consequence to the project, andshould be raised now.（下述乃完工計劃之主要問題，應現在提出）1.The TACC and TCC Specifications andidentified requiring extensive revision in uniden-tified area....（1.台北區管中心及終端管制中心之規格，在不特定範圍內需要廣泛的修訂）2.The documenta-tion discussion is basically correct, but omitscertain data, including:＊no content or schedule

is defined for Software Development Plan;＊The current status of ongoing dicussions withLILT on the prcedure for handling cast specifications, and the schadule for republishing rejecteddocumnets, and＊the current status of ongoingdiscussions with LILT on the appropriate reviewperiods for various categories of documents. Werecommend that the CAA request clarification of

the disposition of these documentation issues.（2.文件的討論基本上正確，但忽略了特定資料，包括：＊對軟體發展計劃，並未訂定其內容或時程。＊目前正與洛克希德持續進行關於測試規格處理程序之討論；未經許可文件之重新提交時程。＊目前正與洛克希德持續進行關於各類待審文件之適宜審核期間。我們建議民航局應要求洛克希德公司澄清前揭文件之處理議題）3.Questions areraised about GFE interfaces, which are not really

of concern to Lockheed....We recommed that the CAArequest that Lockheed confirm their ability tosatisfy their contactural responbilities for theseinterfaces by simulation,in the absence of speci-fied interfacts（3.關於GFE界面的問題雖有被提出，但此並非洛克希德真正關心之所在，…我們建議民航局應要求洛克希德再次確認，其有能力在所定界面未能取得時，以模擬方式履行契約上義務）。 4.The plan proposethat many'analyses' and' evaluations'be performed

to define the detailed status of the system, butgenerally does not specify how the resulting in-formation is to be made available to the CAA.Werecommmend the the CAA request that Lockheed pro-vide information about the handling of this infor-mation...（4.此計畫雖提出許多系爭系統之「分析」與「評估」，以界定系爭系統之細部狀態，但並未說明如何獲致該項分析或評估之相關資訊。我們建議民航局要求洛克希德提供處理該等資訊之相關資訊）5.The configura-tion management proposals are generally good but

do not adress control over the multiple softwareconfigurations that will be concurrently resident

in the TACC computer systen, We recinnabd that tge

CAA request the Lockheed define the procedurese to

be used to ensure the appropriate control of this'working' software（5.計畫之電腦程式配置管理提案整體雖好，但未說明與TACC電腦內部系統軟體同時運作之數軟體建構之控制方式。我們建議民航局應要求洛克希德界定相關程序，以確保能適當控管系爭系統「運作」軟體）。6.The proposed schedule for the major systemdate.(TACC Conditional Acceptance has TCC-3 FinalAcceptance )are responable.But, the proposed minordates are subject to revision as the results of

the various 'analyses'and 'envaluations' becomeavailble. How ever the lacks intermediate mile-stone during 1988 for progress in developing thesystem fucntional capability,We recommend that…（

6.完工計畫中關於TACC系統與TCC系統之細部交期，尚取決於契約依完工計畫所諸多「分析」與「評估」進行修正後之結果，且在西元1988發展系統之功能性能力時，完工計畫未設定中繼之里程碑時程序，我們建議……）。

7.The additional senior engineers which Lockheedwill assign to the project, to sugment the LILTtechnical staff, are of great interest; but are

not well identified. We command that the CAArequest additional information from Lockheed,including resumes for, and apporximate schedules

for arrrival and departure of the additional staff.Because the Magnavox display firmware update is

on the critical path for the project, and doing

the work at LILT is new, the availability andqualifications of the personnel proposed for thatactivity are of praticular concern. （7.洛克希德公司增加並指派負責完工計畫之高階程式人員，未經確認，建議民航局應要求洛克希德公司提供該等人員之資歷，及抵達與離開之適當時程，因為Magnavox公司顯示器之韌體更新為完工計畫之要徑，而此一工作對洛克希德公司而言為一全新的嘗試，故確保高級程式人員之素質與參與，對完工計畫而言至關重要）……」（見原審被證卷第一冊第

40 至41頁、本院卷廿一第245至247頁），顯然洛克希德飛機公司所提完工計畫，尚有許多不足之處，且邁特公司認系爭完工計畫在技術上健全良好可行，係以洛克希德公司能順利解決上開所述各項缺失為前提條件，非無保留。而依該附件所載，系爭完工計畫台北區管中心及終端管制中心之規格，既在不特定範圍內需要廣泛的修訂，顯見台北區管中心及終端管制中心之規格必須修正，始能洛克希德公司所提完工計畫執行，但完工計畫並未具體指出台北區管中心及終端管制中心之規格應為如何之修正，就其軟體發展計劃，亦未訂定其內容或時程，雖提出許多「分析」與「評估」，但並未說分析或評估所據之相關資訊，亦未說明TACC電腦內部系統數軟體同時運作之控制方式，顯示器之韌體更新為完工計畫之要徑，但此對洛克希德公司為一全新的嘗試，雖計畫增加指派高階程式人員負責，但該等人員之資歷如何不明……，可見系爭完工計畫處處充滿不確定性，實難認係完善可行。

（五）另邁特公司77年6月22日提出第二份評估報告之函文雖稱「……During the past week, MITRE has re-examined

the PCP,and has had discussions with LILT seniorstaff personnel about their recent activities,current status,and future plans. Based on thisinformation, and on our understanding of the CAA'stime and budgetray constraints, we see no reason

to change our recommendation.We see no reason tochange our recommendation. We confirm that Lock-heed understands what must be done to sucessfullycomplete the ATCAS, and we conclude that Lockheed

can do it...Our reasons for reaching this conclu-sion are discussed in the attachment to his letter（邁特上週重新檢視完工計畫，並與洛克希德公司高層人員討論其最近的活動、目前履約狀況及未來計畫，基於這些資訊及我們所了解民航局預算之限制，我們沒有理由改變我們的建議，我們確認洛克希德公司明瞭為成功完成系爭航管工程所需執行的事項，並且我們總結認為洛克希德必將能成功完成系爭航管工程，我們達到此一結論的原因，業已記載於本函之附件...」（見本院卷廿一第248頁、原審被證卷第一冊第42頁），惟其附件則記載「.....5.Project Schedule:For the past few months,Lockheed

has been attempting to adhere to the schedule in

the PCP (which was delivered 0000-00-00), however,they are now slightly behind that schedule. Thedelay can be attributed in vary degrees,to:＊theencountered problems being more complex than hadbeed expected;＊the low morale of the LILT staff,...＊the difficulty in recruiting new expatriatepersonnel,...becouse of this delay, and becauseMITRE believe that correcting the system problemswill be more complex than Lockheed had have to beextended....（在過去數個月中，洛克希德公司一直嘗試遵守完工計畫所定之時程（業已於1988年1月15日提交），然而洛克希德業已落後進度，該遲延之原因：＊完工計畫所遭遇的問題，比預期更為複雜。＊洛克希德公司團隊士氣低迷…．＊國外人才難以募集……由於前述遲延，且邁特公司認為修正系統問題之複雜性比洛克希德原先所估計的更為複雜，所以完工計畫之時程勢必展延）」等語（見本院卷廿一第249至251頁、原審被證卷第一冊第45至54頁），亦已載明其雖認為洛克希德公司如果能解決其評估報告所載問題，應可完成系爭航管自動化系統，但其對於洛克希德公司能否解決評估報告所載問顯，則有疑慮。顯見洛克希德擬定之完工計畫並不完備，尚有更複雜的問題未解決，且洛克希德本身亦無法依其所提完工計畫如期履行。洛克希德公司之完工計畫既低估問題之複雜性，又無能力解決其遭遇人員士氣低迷、人才難以募集等困境，亦無法依照其完工計畫所定時程履行，自難認系爭完工計畫為履行系爭契約適當之補救措施，被上訴人以此抗辯其所提完工計畫為履行系爭契約適當之補救措施云云，並無足取。

（六）又邁特公司負責航管自動化系統之計劃主持人邢承中博士雖於另案第一審到庭證稱：「其拯救方案與其他人比較是肯定的，如果第三人來執行則花費更多的時間和金錢，所以其拯救方案是肯定的」等語，惟其亦證稱 「1987年8月洛克未交貨，即TACC沒有交貨，對民航局是相當重要，原告公司(即本件被上訴人)之軟體發展遇到相當之困難所以造成遲延」、「是為了使民航局能即時完工，才建議民航局」等語（見原審卷三第14至18頁），則可認邁特公司於其評估報告表示完工計畫在技術上可行、洛克希德了解問題之所在、及處理問題所必須採取之行動提出的時程合理、由洛克希德依據他們所提計畫繼續施工，將是完成自動化系統最快速、費用最低、最省力之方式，係於假設洛克希德公司能解決其評估報告所載各項缺失及技術上問題之前提下，考量洛克希德已進行多年，認由洛克希德繼續履行契約，可能較民航局重新招標，能較快完成航空自動化管理系統，基於民航局時程與經費之限制，所為之建議，非謂系爭完工計畫亳無缺失確實可行。

（七）況邢承中博士（Dr.C.C.Hsin） 曾於79年2月2日函民航局稱：「Lockheed deliberately use incomplete,mis-leading, and false reference to MITRE documents toinfluence thie ROC Court (see Reference 1 and 2).MIRTE did not give Reference 1 or Reference 2 toLockheed or even show them to Lockheed. Lockheed'sargument in court is weak and can be easily over-come by the overwhelming weight of negative evaluations that are present in the very same documents

and in many similar lttters.（洛克希德公司處心積慮的引用不完整、誤導與不實在的邁特文件，以圖影響法院裁判(詳參考文件1、2)，惟邁特並未提供前開參考文件1、2給洛克希德公司。 洛克希德公司在法院上之論點不充分，且易為同一文件或其他類似函件中所示之負面評估意見所推翻）。....Lockheed proposed are covery planwhich,as delivered, was unacceptable to both the

CAA and MIRTE unless some important flaws in theplan were resolved（洛克希德公司所提之補救計劃，未為民航局與邁特公司所接受，除非該計畫中某些重大之缺失已先被解決） ...The PCP was seriously flawed andwould have required extensive revisions.（該完工計畫確有嚴重的瑕疵並需大幅度的修正）. Lockheed has

not acknowledged the flaws in their Project Com-pletion Plan. MIRTE recognized the flaws and re-ported these flaws the the CAA;Lockheed's argue-ment in court is based upon providing this longoverdue recovery plan after years of poor perfor-mance on the contract （洛克希德公司不瞭解其完工計畫之瑕疵，邁特則早已看出，並悉數告知民航局。而洛克希德公司在法院所提論點，無非係根據其在多年履約情況不良後，已提供一個將導致長期延誤之補救計畫）.In aMIRTE review of the Lockheed system status in May1988 (Refer- ence 6）,MIRTE concluded that: Thesystem has a number of problems,which will requireextensive further development and test. Theseproblems had beev anticipated in the PCP,and itsschedule provides for the additional effort.How-ever, the severity of the problems may have beenunantici- pated, and the PCP schedule may require

an appro- priate revision. （在1988年5月，邁特曾檢視洛克希德公司之系統執行狀況(詳參考文件6) ，邁特的結論為：『系統有許多問題，需要更廣泛與更多的發展與測試。這些問題在完工計畫中早已被提及，並由其所提報之進度表可看出尚需很多的額外工作，然而，對於該等問題之嚴重性卻超出預期之外，因此該完工計劃進度表可能需要再做適切的修正。』） During 1987,the CAA andMIRTE were engaged in a major reevaluation of theATCAS Project including exploring complete rene-gotiation with Lockheed on program cost and sche-dule.MIRTE stated at that time (Reference 7)that:

◇There are viable alternatives, but nothing riskfree.◇Based on Lockheed performance, there is abasis to ter- minate Lockheed.（1987年，民航局與邁特公司曾共同參與航管自動化系統的重估工作，包括嘗試重新討論洛克希德公司計畫之費用與進度表，邁特在當時曾報告（詳參考文件7)：◇有很多可行的解決方案，但每一方案均有風險。◇根據洛克希德公司履行契約之績效來看，有終止合約之立場。）...Before the contract wascancelled, in their letters and in the ProgramCompletion Plan, Lockheed appeared to be jockeying

for adversarial advantage over the CAA by a biasedaccount of the history of the project.This biasedaccount,inconsistent wirh the boty of document-ation available on the progress of the contract,continued in the material Lockheed presented to

the ROC court.The CAA was justified Lockheed indoubting Lockheed's commitment to completing thecontract to the CAA's satisfaction (i.e.completing

the programs within the contractual schedule andbudget). In fact, the false and misleading argue-ments Lockheed presents to the court could betured into evidence of why Lockheed was cancelled（在解約以前，洛克希德公司在其信函及完工計畫書中，曾刻意扭曲事實，以造成對民航局不利的論點，該等與歷次進度報告不一致的扭曲論點，在洛克希德公司提送法院的資料中仍繼續出現，民航局對洛克希德公司能否圓滿完成合約之承諾，不得不抱持懷疑態度（例如：能否在合約規定之預定進度表內完成計畫），事實上，洛克希德公司提送法院之虛假、誤導之論點正可能是其被解除合約的原因）」等語（見原審卷五第429至431頁）。已說明洛克希德公司如何斷章取義，引述邁特公司77年1月27日及77年6月22日評估報告函文片段之內容，曲解為有利於已之論點。洛克希德公司所提完工計畫，既仍有諸多嚴重缺失，並有複雜的問題未解決，能否依其所提完工計畫如期履行，亦有疑慮。則由完工計畫之實質內容觀之，亦難認係適當之補救計畫。

八、中信局可否依闡明條款第5.3.1.a條terminate系爭契約？中信局於76年12月1日發函催告及於77年6月25日發函依闡明條款第5.3.1.條「terminate」系爭契約是否合法有效？

（一）查中信局於76年12月1日致函洛克布德飛機公司稱「TheCTC/CAA hereby notifies Lockheed of its intent toterminate the reference contract in accordancewith section 5.3.1 of the contract, unlessappropriate action to cure such failure.including

the provision of an affirmative project recoveryplan satisfactory to CTC/CAA,shall have been takenwithin 60 days after thereceipt of this notice.」。嗣又於77年6月25日發函通知洛克希德飛機公司稱「……Unfortunately, our client, Civil AeronauticsAdministration, advised this office that thesecontractual obligations have not been completed byyour esteemed firm and this office have no otherchoice but to terminate the whole contract pur-suant to article 5.3.1 of the Clarifications tocontract terms and condition and record the case

as a default on your part.」有上開信函在卷可稽（見原審原證卷一第60、62頁）。

（二）按系爭契約闡明條款第5.3.1.a條規定「The CAA shall,subject to the provisions of paragraph c below,

to give sixty (60) days notice in writing to LEC

of CAA's intention to terminate the whole or anypart of this contract in any one of the followingcircumstances:（民航局於下列任一情形發生時，除應依下述ｃ款處理外，應於60天前以書面通知洛克希德電子公司表示民航局欲terminate全部或部分契約之意思） (i)

If LEC fails to make delivery of the equipment or

to perform the services within the time specified

or any extension thereof; or (ii) If LEC fails toperform any of the other provisions of this con-tract,or So fails to make progress as to endangerperformance of this contract in accordance with

its terms, and in either of these two circum-stances does not take appropriate action to curesuch failure within a period of sixty (60) days(or such longer period as the CAA may authorize inwriting)after receipt of notice from the CAA spec-ifying such failtire（1.若洛克希德電子公司無法在規定期限內或寬延期限內，交付設備或履行服務；或2.洛克希德電子公司無法履行本合約任何條款，或無所進展以致危害到合約之履行，於此兩種狀況之一發生，並在接獲民航局指出該無法履行情事之通知後60天內（或民航局以書面授權之延長期限內），未採取適當之補救措施）」（見原審原證卷第一冊第56至58頁、本院卷十二第44至45頁）。

（三）次查系爭契約於簽訂後，迭經修正，將完工期限變更為：㈠TACC系統為76年8月30日、㈡台北TCC系統為76年11月30日、㈢高雄TCC系統為77年2月29日、 ㈣台中TCC系統為77年5月30日，惟迄至76年11月30日， 洛克希德公司並未完成上開任何一項系統，未依期交付TACC系統，又無闡明條款第4.1條及第4.2條第1項各款所定可調整展延完工期限之情事，履行契約已有遲延，已如前述。又民航局於76年12月1日依闡明條款第5.3.1條發函通知洛克希德，除非洛克布德能於60日內提出可治癒已發生及可預見遲延之適當之補救計畫，否則將terminte系爭契約，洛克希德公司雖於 77年1月15日提出完工計畫，但該完工計畫並非能可治癒已發生及可預見遲延之適當之補救計畫，已如前述。則民航局嗣於77年6月25日發函依闡明條款第5.3.1.條「terminate」系爭契約，自屬合法有效。

九、中信局依闡明條款第5.3.1.a條terminate契約之法律效果為契約解除或終止？ 契約terminate後，雙方權利義務關係如何？系爭契約條款有無排除或優先於民法相關規定之適用？

（一）查「terminate」 一字依梁實秋所編遠東英漢大辭典，係指終止、終結、結束之意（見原審卷㈤第60頁） ，又依BLACK'S LAW DICTIONARY，係指「To put an end to;tomake to cease; to end」、「With respect to a lease

o contract, term refers to an ending, useually be-fore the end of the anticipated term of the lease

or contract, which termination may be by mutualagreement or may be exercise of one party of one

of him remeides due to the default of the otherparty.（在租賃或契約中，係用以指稱結束，通常在租賃或契約期間屆至前為之，其可為雙方合意或可由一方基於他人之違約而行使之」（見原審卷㈥第117頁）； 又依美國統一商法典 ，terminate係用於契約之任一方結束契約之情形，且終止時雙方之前所已發生之權利義務仍具執行力而未被免除（Termination occurs when either partypursuant to a power created by agreement or lawputs and end to the contract otherwise than for

its breach. On termaintion all obligations which

are still executory on both sides are dischared

but any right based on prior breach on performancesuvives） （見原審卷㈥第120至121頁）；另司法院出版「英譯中華民國主要法規第二輯」 中關於民法第259條所定解除權之行使，係譯為 「Unless otherwise provided

for by law or by contract, each party must, incase of『rescission』, restore the other party to

his...」 ，而民法第511條承攬契約之終止，則翻譯為「

The employer may 『terminate』 the contract at anytime..」（見原審卷㈥第124至125頁），被上訴人主張系爭闡明條款第5.3.1.a條之「terminate」，係指終止契約之意，尚非無據。

（二）上訴人雖主張闡明條款第5.3.1條規定「The CAA shall..terminate the whole or any part of this contract」，而系爭契約迄至 77年6月25日已進行近五年，只能向將來終止部分契約，不可能終止全部契約，且其於 77年6月25日信函更明確請求被上訴人於 77年7月25日前返還已付全部價金，故該terminate係指解除契約之意云云。 惟系爭契約之內容包括整個航管系統之系統分析、軟體之初步設計與細部設計、硬體設計建置，並有TACC系統及三個終端TCC系統， 民航局自得往後的終止契約之全部或一部分。而民航局於終止契約函為如何之請求，係民航局主觀上之要求， 應尚不得以而認闡明條款中terminate一詞係為解約之意。況闡明條款第5.1條至5.3條有多處均使用ter-minate一詞，其中第5.2條b項(iv)(vi)款、d項、e項(ii）款、h項、第5.3.1條c項、d項(i)(ii)(iii)款均約定由民航局受領工作並給付一定報酬，顯與解除契約之效果不同。上訴人主張其依闡明條款第5.3.1條terminate 系爭契約，即生解除契約之法律上效果，應無可取。

（三）系爭契約經上訴人依系爭闡明條款第5.3.1.條a款終止後，雖闡明條款第5.3.1條c款規定「If this contract isterminated as provided in paragraph a of thisclause, the CAA,in addition to any other rightsprovided in this clause, may require LEC to trans-

fer title and deliver to the CAA，in the manner

and to the extent directed by the CAA, (i) anycompleted supplies, and (ii)such partially com-pleted supplies and materials, parts, tools,dies,jigs, fixtures, plans, drawings and informationwhich LEC has the right to transfer and deliver(hereinafter called "manufacturing materials") andwhich has been specifically produced or specifi-cally acquired by LEC for the performance of suchpart of this contract as been terminated;and LECshall upon direction of the CAA protect and pre-serve property in the possession of LEC in which

the CAA has an interest. Payment for manufacturingmaterials delivered to and accepted by the CAA and

for the protection and preservation of propertyshall be in an amount agreed upon by LEC and CAA.（若本契約係依本條ａ項而終止，民航局除具有本條規定之其他權利外，並得請求洛克希德電子公司依其指示之方式及程度，移轉所有權及交付下列洛克希德電子公司有權移轉及交付，以及洛克希德電子公司在契約終止前，為履行契約所特別製作或獲得之物品： （i）任何完成的供應品， 與（ii)部分完成的供應品與材料、零件、工具、鑄模、機架、固定裝置、計劃、圖樣與資訊（以下稱『製造材料』）。洛克希德電子公司必須依民航局指示，保護並保管民航局對之有權益並由洛克希德電子公司占有之財產。對已交付予民航局且經民航局受領之製造材料應行支付之金額，及對此等財產之保護與保管應行支付之金額，由洛克希德電子公司與民航局雙方協議）」（見原審原證卷㈠第57頁）。 既約定民航局「得請求（may require」洛克希德電子公司依其指示，移轉交付供應品、製造材料而給付該部分之價金，應係賦予民航局選擇是否請求洛克希德電子公司移轉交付供應品或製造材料之權利，則如民航局未曾要求洛克希德電子公司交付任何供應品或製造材料，並予以受領，即無依該條款給付供應品或製造材料價額之義務。上訴人主張其未曾指示洛克希德電子公司交付移轉任何供應品或製造材料，被上訴人亦未舉證民航局曾指示交付並受領任何供應品或製造材料，則本件應無闡明條款第5.3.1條ｃ款之適用。

（四）又闡明條款第5.3.1條ｄ款規定「If, after notice oftermination of this contract under the provisions

of this clause, it is terminated fot any reasonthat LEC was not indfault under the provisions ofthis clause, or that the default was excusable therights and obligations of the parties shall be asfollows:... （若依本條規定發出終止契約通知後，因任何原因確定洛克希德電子公司並無本條所述違約情形，或該違約係可宥恕者，則雙方之權利義務依下述規定…）」，是就洛克希德電子公司無違約或可宥恕之情形，所為之規定，本件洛克希德電子公司確有未能依期履行契約之違約情形，已如前述，自亦無本款之適用。被上訴人主張終止契約後雙方權利義務應依本款之規定定之，應無可取。

（五）又中央信託局購料處國外採購合約第20條規定「In case

any supplies are rejected within the guarenteedperiod, the Seller, upon receipt of CTC's notice,shall despatch repleacement(s) at hte earliestpossible date, Such additional costs asinsurance,freight, charges,fees,duties and other relevantexpenses involved inshipment of the replacement(s)

and rejected supplies shall be borne by the Seller

But the rejected supplies shall not be shippedback to the port of origin until the replacement

is accepted by CTC or its client. In the case CTCreject any defective or nonconforming supplies anddoes not require replacement(s), or in case theSeller fails to make a replacement shipment withinthree months after receiving CTC's notice, theSeller shall refundto CTC such portion of the Con-tract price of the supplies as in equitable in thecircumstances. In case CTC accepts the defetive ornoncomforming or a part thereof with a claim forcompensation, the Seller shall pay CTC such com-pensation within one month after receivinig CTC'snotice; otherwise, CTC will collect the compensa-tion from the performance bond.If,upon collectionfrom the performance bond, there is still anydefference due to CTC,the Seller is liable forsettlement of the compensation. （在保證期間內如有退貨情形發生，售方應於收到本處通知後，儘速換貨。因換貨及退貨所需之一切費用，包括保險費、海運費、進口稅捐及其他費用概由售方負擔；退還之物品，應俟售方辦妥換貨並經買方接受後始得運回。凡不符或有瑕疵貨品不需換貨者，或售方到本處通知後三個月內未辦妥換貨者，售方應依當時公平合理條件，退還價款。又本處同意由售方賠款以接受不符或有瑕疵貨品者，售方應於收到通知後一個月內繳付賠款，否則本處將自履行保證金內扣抵，如有不足，仍應由售方負責理楚）」，係就換貨退貨所為之規定，與終止契約之情形，尚屬有間，上訴人主張終止契約後雙方權利義務應依國外採購合約第20條規定定之，亦無可取。

（六）兩造契約文件就上訴人依闡明條款第5.3.1條ａ款終止契約，且未指示要求洛克希德電子公司交付移轉任何製造材料時，契約雙方應負之權利義務為特別之規定，而本件契約之性質應屬承攬契約，並以我國法律為準據法，已如前述。則契約終止後兩造間之權利義務，即應回歸我國民法之規定。

十、上訴人可否依民法第259條、第179條及系爭契約之國外採購契約條款第20條規定，請求被上訴人返還已付之價金及原判決附表二所示之利息？及其數額？

（一）本件與系爭契約之國外採購契約條款第20條規定之情形不同，並無該條之適用，已如前述，又系爭契約係上訴人依闡明條款第5.3.1條ａ款終止，並非解除，且民法第259條關於契約解除後回復原狀之規定， 依民法第263條規定，於終止契約之情形並無準用，上訴人依國外採購契約條款第20條、民法第259條規定， 請求被上訴人返還已付之價金及原判決附表二所示之利息，自屬無據。

（二）又本件契約之性質應屬承攬契約，已如前述。而按稱承攬者，謂當事人約定，一方為他方完成一定之工作，他方俟工作完成，給付報酬之契約。約定由承攬人供給材料者，其材料之價額，推定為報酬之一部， 民法第490條定有明文。又終止契約，僅使契約自終止之時起向將來消滅，並無溯及效力，當事人原已依約行使、履行之權利義務，不受影響。而在終止前，原承攬契約既仍屬有效，定作人自仍應給付承攬人已完成工作部分之報酬，且承攬人於契約終止前所受給付，既係本於斯時有效之契約，自有法律上之原因，固無不當得利之可言（最高法院96年台上字第97號判決意旨參照），惟一般承攬契約約定分期支付工程款者，其先數期之工程款多含有未完成部分之工程款在內（最高法院83年台上字第927號判決意旨參照） ，則若定作人分期支付之工程款中含有未完成部分之工程款在內，因承攬契約已因終止而向將來消滅，承攬人所受領未完成部分之工程款，即屬民法第179條後段所定 「雖有法律上原因，而其後已不存在者」之情形，定作人應可依不當得利法律關係請求返還。

（三）查本件系爭航管自動化契約文件約定付款方式分為美金付款及新台幣付款二部分，美金付款部分又分為TACC及TCC二部分： ㈠TACC部分約定：⑴頭期款（Downpayment）於簽署契約時支付美金價款之15%、⑵PDR款，於CAA簽署Certificate of Completion時支付美金價款10%、 ⑶CDR款，於CAA簽署Certificate of Completion時支付美金價款22%、⑷設備裝船CIF台北時依3.7.5節支付美金價款28%、⑸……㈡TCC部分約定： ⑴頭期款於簽署契約時支付美金價款之15%、⑵PDR款，於CAA簽署Certificate of Com-pletion時支付美金價款10%、⑶CDR款，於CAA簽署Certi-ficate of Completion時支付美金價款22%、 ⑷設備裝船CIF台北時依3.7.5節支付美金價款7%、⑸……。新台幣付款部分約定：⑴頭期款於簽署契約時支付新台幣價款之15%、⑵TACC PDR款，於CAA簽署Certificate of Comple-tion時支付新台幣價款5%、⑶TACC CDR款，於CAA簽署Certificate of Completion時支付新台幣價款5%、⑷TCCPDR硬體款 ，於CAA簽署Certificate of Completion時支付新台幣價款5%、 ⑸Delivery of TACC System to Site款，於民航局簽收時支付新台幣價款15%、⑹TCC PDR軟體款，於CAA簽署Certificate of Completion時支付新台幣價款5%、⑺TCC CDR款，於CAA簽署Certificate of Comp-letion時支付新台幣價款5%、⑻……見外放中央信託購料處合約卷夾第8-11頁、本院卷廿三第23至25頁）。

（四）又上訴人已於72年12月29日給付洛克希德公司美金部分之頭期款4,732,787美元、新台幣部分頭期款45,334,800元，已據上訴人陳明在卷，並有美金付款之INVOICE、中央信託局購料處簡便行文表在卷可稽 （見本院卷廿四第165頁、卷十一第44頁、第97頁）。 而契約付款條件第1.7節約定「The Downpayment Bonds will be limited to theamount of the initial payment only. The downpay-ment bonds will be liquidated as follows:The first15% downpayment will be liquidated in proportion

to the subsequent payment terms for the TACCwherein the bonds will be totally liquidated onconditional acceptance of the TACC.This schedulereflects that the CAA will have full use of theTACC system plus most of the remaining TCC systemequipment will have been delivered to the ROC.」（見外放中央信託購料處合約卷夾第4-5頁） ，中信局既於簽約時即給付洛克希德公司美金總價15%及新台幣總價15%之價款，且約定於後續所付款項中依比例扣回， 而嗣中信局嗣亦確已扣回部分美金頭期款1,183,196.75元，及部分新台幣頭期款11,333,700元（見上訴人起訴狀附表二，本院卷廿四第165至166頁），上訴人主張其所付頭期款原屬預付款之性質，尚非無據。又頭期款既約定於後續所付工程款中逐次按比例扣回，則尚餘未扣回部分，自仍屬預付款之性質。而系爭契約既已終止向將來消滅，則洛克希德公司所受領此部分頭期款之法律上原因，即已不存在，則上訴人請求洛克希德公司返還所餘美金頭期款3,549,

590.25美元及新台幣頭期款34,001,100元，即屬有據。

（五）又上訴人已先後於 73年9月14日給付洛克希德公司TACC之PDR美金部分報酬1,329,857美元，於74年12月31日給付洛克希德公司TACC第一階段CDR部分美金報酬664,928美元，於75年9月27日給付洛克希德公司TACC第二、三階段CDR部分美金報酬1,329,856美元，於 76年4月3日給付洛克希德公司TCC之PDR美金部分報酬1,825,335美元， 已據上訴人陳明在卷，並有各次付款之INVOICE在卷可稽 （見本院卷廿四第165頁、卷十一第45至47頁）。另上訴人亦於73年9月15日給付洛克希德公司TACC之PDR新台幣部分報酬新台幣15,111,600元、於74年12月24日給付洛克希德公司TACC之CDR新台幣部分第一階段報酬新台幣5,037,200元、於75年11月4日給付洛克希德公司TACC之CDR新台幣部分第二、三階段酬新台幣10,337,468元、於75年12月1日及76年4月3日分別給付TCC之PDR新台幣部分報酬各新台幣15,506,201元、亦據上訴人陳明在卷， 並有中央信託局購料處簡便行文表、中央信託局信託處函，及各次付款之統一發票在卷可稽（見本院卷廿四第166頁、卷十一第97至103）。

（六）而系爭航管自動化系統TACC之PDR部分，已於73年8月31日完成，有民航局之函文及其出具之Certificate of Com-pletion載明「The Civil Aeronautis Administration

(CAA) hereby certifies that, under the terms ofContract No:83- GF3-4330 and in accordance with

the requirements of Letter of Credit No.0000-0000,Lockheed Internaional Limited Taiwan has completed

the Preliminary Design Review (TACC）」 （見本院卷十九第476至477頁）。 又TACC之CDR部分，已於75年9月5日完成大有民航局之函文出具Certificate of Comple-tion載明「The Civil Aeronautis Administration（CAA）hereby certifies that,.....Lockheed InternaionalLimited has completed the second and third partsofthe Critical Design Review (TACC）....」（見本院卷廿三第185至186頁）。 另TCC之PDR部分，亦已於76年3月20日完成，亦有民航局之函文及其出具之Certificate

of Completion載明「The Civil Aeronautis Adminis-tration (CAA) hereby certifies that,....LockheedInternaional Limited Taiwan has completed the Pre-liminary Design Review (TCC）」（見本院卷十五第655至657頁），惟TCC之CDR部分，則迄至77年6月25日上訴人終止契約時，仍尚未完成，為兩造不爭。洛克希德公司於系爭航管自動化契約終止前，既已完成TACC之PDR、TACC之CDR及TCC之PDR部分，依首開說明， 終止契約並無溯及效力，在終止前原契約既仍屬有效，定作人即上訴人自仍負應給付已完成工作部分之報酬之義務，洛克希德公司取得上開報酬亦非無法律上原因，則上訴人請求被上訴人返還此部分款項，即非有據。

（七）上訴人固主張上揭民航局出具之TACC PDR、CDR及TCC PDR之Certificate of Complement是各該階段之結束證明，不是完成證明， 因為核發Certificate of Complement時洛克希德公司尚有PDR、CDR之待辦事項尚未完成云云。查民航局固於給付TACC PDR款後之 73年9月21日去函洛克希德公司表示：「...PDR really isn't over yet. There

are still missing/incomplete/incorrect material to

be provided/corrected, and action items to be re-solved...」（見本院卷廿三第55頁）；於給付TACC CDR款後之75年11月26日去函洛克希德公司表示：「CAA hasreceived the responses from LILT for all the TACC

DRC closure items,but CAA feels that the responses

do not fully addressed all of CAA's concerns...CAAwould like to have a meeting with LILT, to discuss

our concerns, after the completion of the TCC FDP

PDR.」（見本院卷廿三第59頁）； 於給付TCC PDR款後之76年5月8日去函洛克希德公司表示：「....The intents

is to confirm that Lockheed and CAA are in agree-ment about the approach to be taken in resolving

the issues.」（見本院卷十五第687頁）。惟按「承攬人完成工作，應使其具備約定之品質，無減少或滅失價值或不適於通常或約定使用之瑕疵， 固為民法第492條所明定，惟此乃有關承攬人瑕疵擔保責任之規定，與承攬工作之完成無涉。倘承攬工作已完成，縱該工作有瑕疵，亦不得因而謂工作尚未完成」（最高法院85年度台上字第2280號判決意旨參照），民航局既已出具TACC PDR、TACC CDR及

TCC PDR之Certificate of Complement，而Completion之字義即為完成、結束，民航局既已出具證書面表明TACC之PDR與CDR及TCC之PDR已完成，此部分當己完成，則洛克希德公司於系爭契約終止後，自得請求已完成之該部分之報酬。洛克希德公司就TACC之PDR與CDR及TCC之PDR部分，縱尚有為解決民航局上開信函所指疏漏、錯誤之待辦事項未完成，亦僅係洛克希德公司應否負瑕疵擔保責任之另一問題，上訴人以此主張洛克希德不得領取此部分之報酬，尚非可取。

（八）上訴人雖又主張其所付各期款項均為報酬預付之性質，PDR款及CDR款之給付，僅依契約之預定時程與總價金之一定比例辦理付款而已，與PDR及CDR有無具體之工作成果無關云云。惟查系爭契約約定之美金及新台幣之價金及付款時程，TACC及TCC之PDR、CDR款，均分別於「Certificate

of Complement signed by CAA at Completion of PDR」，及「Certificate of Complement signed by CAA atCompletion of CDR」時支付 （見外放中央信託購料處合約卷夾第8-11頁、本院卷廿三第23至25頁），足見洛克希德公司須於完成TACC系統之PDR、CDR或TCC系統之CDR時，方可請求該部分之款項， 參諸TACC之CDR分為三個階段，上訴人亦分第一階段及第二、三階段，二次付款，且給付

PDR CDR款INVOICE之摘要分別記載：「Completion ofPreliminary Design Review (PDR) for the Taipeiarea control centre (TACC) system, in accordancewith...」、「Completion of the first part ofCritical Design Review (CDR) for the Taipei areacontrol centre (TACC) system, in accordance with..」、「Completion of the second and third part ofCritical Design Review (CDR) for the Taipei areacontrol centre (TACC) system, in accordance with..」、「Completion of Preliminary Design Review

(PDR)for the Terminal Control Centre (TCC) system,inaccordance with...」（見本院卷十一第45至48頁），可認洛克希德公司領取之TACC PDR、CDR款及TCC PDR款，非屬預付款之性質，而為洛克希德公司完成TACC PDR、CDR及TCC PDR之報酬，上訴人主張洛克希德公司取得上開款項，無法律上原因其可依民法第179條請求返還， 應非可取

（九）又上訴人自 73年11月13日至76年8月14日共支付洛克希德公司器材款合計美金4,760,879.27元之事實，已據上訴人列表陳明在卷，並有各次付款之INVOICE在卷可稽 （見本院卷廿四第165頁、卷十一第49至96頁）。 又依系爭契約約定之美金價金及付款時程所載， 器材款係於設備裝船CIF台北時給付（見外放中央信託局購料處合約卷夾第8至9頁、本院卷廿三第23頁） ，而本件系爭航管自動化契約為承攬契約之性質，已如前述， 而依民法第490條規定，承攬人於為定作人完成一定工作後，始得請求給付報酬，是承攬之報酬係採後付主義，而於承攬契約經契約終止之情形，因終止前承攬契約仍屬有效，定作人固仍負有給付報酬之義務，惟依報酬後付原則，承攬人可請求報酬者應以契約終止前已完成之部分為限。又本件契約標的為航管自動化系統，而該系統係依系統規格及設計，由多數軟、硬體設備，逐層組裝、連結、測試而成，故任一設備之器材之裝船啟運、到達台北，甚至單一設備硬體之安裝，均非可認為工作之完成。且依系爭契約美金價金及付款時程表，TACC器材款為TACC美金總價之28%，金額為3,723,590元，TCC器材款為TCC美金總價之7%，金額為1,277,734元（見外放中央信局購料處合約卷夾第8至9頁），而上訴人支付TACC器材款之invoice均記載「In accordance withL/C Payment Schedule (AttachmentⅡ)amount of$3,723,599 for shipment of TACC equipments repre-sents approximately 62%（或63%）actual equipmentvalue」，而依裝船器材價金之62%或63%於器材裝船時付款，給付TCC器材款之invoice均記載「In accordancewith L/C Payment Schedule (AttachmentⅢ)amount of$1,277,734 for shipment of TCC equipments repre-sents approximately 5% actual equipment value」，而依TCC裝船器材價金之5%於設備裝船時付款（見本院卷十一第49至96頁），亦足見上訴人係就洛克希德公司所提供之器材之價值，依一定比例於器材裝船時預為付款，與洛克希德公司是否完成設備軟硬體之組裝、連結、測試無關，應非洛克希德完成一定工作之報酬。而依上訴人所提航路自動化系統進度表，契約終止時TACC系統硬體設備固已運至大廈，但各項測試均未完成，另TCC系統之硬體架設及軟體測試亦均未完成（見原審卷五第427至428頁），被上訴人亦未據提出上訴人有簽收任何設備之證據資料，難認洛克希德公司已完成任何設備之軟硬體組裝測試。而承攬之報酬係採後付主義，洛克希德公司既未完成上訴人給付器材款之器材所組裝之設備，系爭契約又已不存在，則上訴人依民法第179條規定，請求洛克希德公司返還此部分款項美金4,760,879.27元，即非無據。

（十）被上訴人雖以邁特公司評估報告亦載明TACC所需硬體均已架設完成，TCC亦有部分硬體已架設完成， 抗辯契約終止時，洛克希德公司就系爭航管自動化工程已完成部分之金額為美金43,518,100元，另案成大航太所賠償鑑定報告亦認洛克希德公司已完成部分為美金31,901,226元，均遠逾洛克希德公司已收受之工程款，上訴人不得請求返還已付價金云云。惟查：

１、上訴人認洛克希德公司於系爭契約終止就系爭航管自動化工程已完成之工程，僅為被上訴人片面之主張，並未經上訴人簽認，難認為真正。又邁特公司77年6月22日第二份評估報告，就工程之現況固記載「...b.TACC Hardware

All required TACC hardware has been installed.....

c.TCC Hardware The TCC hardware is partially installed,...」 （見原審被證卷第一冊第48頁），惟本件航管自動化系統係由多數軟、硬體設備，逐層組裝、連結、測試而成，硬體架設後尚需灌裝配合之軟體與韌體，經測試後，與其他相關設備連結、測試，非設備硬體安裝即可達契約目的，若無相關韌體、軟體並經測試無誤，硬體之設備於上訴人而言即無價值，故系爭航管自動化契約乃約定以「whole lot; turn-key」方式為交易基礎 （見外放中央信託局購料處合約卷夾第1頁） ，依「航路自動化系統（TACC）進度」，TACC部分硬體裝備固已運至大廈，但飛航資料測試、硬體信心測試、硬體組合測試等則均未完成（見原審卷五第427頁)，難認洛克希德公司請求TACC硬體報酬之條件已成就。 另TCC部分依「航路自動化系統

（TCC）進度」，TCC部分不備軟體細部設計審查及測試均未完成，硬體部分已未架設完成 （見原審卷五第248頁），洛克希德公司自尚不得請求此部分之報酬。

２、又另案成大航太所賠償鑑定報告認為洛克希德公司已完成，約內部分之價值為美金29,757,940元，約外部分之價值為美金2,143,286.014元，固有賠償鑑定報告在卷可稽 （見外放鑑定報告），惟該鑑定人於文件編號1000「賠償鑑定報告說明」，已說明：「鑑定資料中出現陸續交貨、安裝及測試的通訊，但不見任何民航局所簽署的收貨單或驗收單。洛克希德公司向民航局提示某硬體已到貨，但並無任何資料顯示民航局任何層級人員簽署『查收』的證據。因此賠償鑑定工作只能以洛克希德公司的陳述為基礎，依照合約進度，陸續交貨及安裝」、「97年1月另案法官到現場會勘時，硬體部分已無法依據清單一一檢視，更因主電腦已不在原地，軟體部分更不可考」、「…本鑑定工作僅依據當時的投入人力，來評估工作可以達到的成效」、「由於洛克希德提出的人力組織無法採信，因此，僅就以當年的每位員工每週簽到的記錄表來搜尋可能的人力部署…洛克希德公司所留下的資料儲存於基隆倉庫中，曾經不慎遭到淹水浸泡。本項鑑定選擇以一個單季（三個月）其中一週的簽到資料，隨機抽檢。因為許多簽到資料已糾結在一齊，無法一一分開點數，改以紙張重量為基礎。本鑑定所提之人力部署計算方式，經實際抽檢部分資料，以重量換算簽到單……隨機抽樣將倉庫中的人員簽到單保存比較完好的，大概間隔約三個月抽出一週份，檢視當時的人力部署，以為洛克希德公司投入人力評估之依據…」、「軟體評估以一個軟體執行功能的複雜性、技術性、即時性、以及時脈速度等，去評估最小單元模組所需的軟體行數……依據熟練的工程師能力，每行軟體的工時的估價者都是固定的，也依據這個基礎，估算出軟體發的成本，並以單行撰寫為計價基礎」等語，已可見洛克希德公司就該鑑定報告所鑑定之項目，均未完成交付民航局收受，且該鑑定報告係以洛克希德公司的陳述為基礎，並以洛克希德公司人員簽到單之重量評估洛克希德公司投入之人力，再以每行軟體撰寫之估價，計算洛克希德公司投入人力之價值，而非以洛克希德公司實際已施作部分依系爭契約約定之報酬計算之數額，已難認係洛克希德公司已施作部分依系爭契約約定計算之報酬。

３、且上開成大航太所賠償鑑定報告已認定洛克希德公司就「陰極射線管顯像器」、「應用軟體」、「系統安裝」、「發展設施」、「訓練」及「文件」部分均未完成，既未完成，應尚未符可請求給付承攬報酬之要件。又上開鑑定報告雖認就「雷達資料抽讀器」、「電腦及周邊設備」、「OAO轉包之軟體工程」、「支援硬體之TACC台北地區管制中心、TCC終端管制中心」部分，洛克希德公司已完成100%，惟 97年元月另案法官至現場履勘時，硬體部分已無法依據清單一一檢視，更因主電腦已不在原地，軟體部分更不可考等情，已載明上開鑑定報告之說明，上開賠償鑑定報告並確認查無任何資料顯示民航局任何層級人員簽署查收「雷達資料抽讀器」、「電腦及週邊設備」、 「OAO轉包之軟體工程」、「台北區管制中心」及「終端管制中心」等之證據，亦難認該些部分工作之進行已達可交付之程度。另關於所謂「約外工程」部分，上開鑑定報告係依權重比評估其認係約外之四項工作之責任工時，占洛克希德約外求償總時數之比率，計算求償金額，但並未具體說明相對應之內容及其取決之方式，其所為計算已難遽取，且被上訴人主張之約外部分，經核均非約外需求已如前述，既非約外要求，自無另依工時請求報酬之依據。被上訴人主張洛克希德公司於契約終止時就系爭航管自動化工程已完成之部分可請求之報酬已逾洛克希德公司已收受之工程款，上訴人不得請求返還已付價金云云，並無足取。

（）又按契約解除時，依民法第259條第2款規定，由他方受領之金錢，固應附加自受領時起之利息償還，惟本件系爭契約係經上訴人依闡明條款第5.3.1.a條終止，已如前述，系爭契約既非經解除，則上訴人主張被上訴人應自其付款日，計付利息，即非有據。

十一、上訴人可否依民法第250條及系爭契約闡明條款第10條規定，請求被上訴人給付遲延罰款？及其數額？

（一）按當事人得約定債務人於債務不履行時，應支付違約金。違約金，除當事人另有訂定外，視為因不履行而生損害之賠償總額。其約定如債務人不於適當時期或不依適當方法履行債務時，即須支付違約金者，債權人除得請求履行債務外，違約金視為因不於適當時期或不依適當方法履行債務所生損害之賠償總額。民法第250條定有明文。 又兩造系爭契約闡明條款第10條規定「"The Article 18 ofCTC's Conditions of Contract shall not apply;how-ever, the Contractor shall achieve the acceptancetesting of each of the systems within the time asspecified in the Contract, otherwise the Contrac-

tor shall pay to CTC a penalty in am amount to becalculated on the basis of 0.05% of the Contractprice of the delayed system for each day of delay"However in no event shall teh total penalty for

any delay system exceed 6% of the contract price

for the delayed system. Also, inthe event that theContractor shall achieve the acceptance testing of

the TCC system earlier that the times as specified

in the contrct,CTC shall reduce any penalty by anamount clalulated on the basis of 0.05% of thecontract price for each system for each day that

the contractor delivers the TCC system earlierthan the time specified in the contract. Specifi-cally excluded is early delivery of the TACC. In

no event shall the contract price be increased askresult of these calculations. （「中信局國外採購合約條款第18條之規定應不予適用，但，承包商應於契約規定時間內完成每一系統之驗收測試，否則承商應向中信局支付按日依被延誤系統契約價款0.05% 之金額計算之罰金」，但在任何情形下，任何被延誤系統之罰金總額不得超過該系統契約價款之6%。同樣地，若承包商早於契約規定時間完成TCC各系統之驗收測試時， 中信局應按提早交付TCC系統之天數，依每一系統契約價款0.05%計算之金額，按日減少罰金之金額。TACC提早交付則不包括在內。在任何情形下，契約價款不得因本項計算而增加）」。又系爭契約簽訂後於74年8月8日第四次修正時，將完工期限變更為：㈠TACC系統為76年8月30日、㈡台北TCC系統為76年11月30日、㈢高雄TCC系統為77年2月29日、 ㈣台中TCC系統為 77年5月30日，為兩造所不爭，並有契約第四次修正資料在卷可稽（見原審原證卷一第37頁） ，惟迄至77年6月25日上訴人終止契約時，洛克希德公司並未完成上開任何一項系統， 又無闡明條款第4.1條及第4.2條第1項各款所定可調整展延完工期限之情事，已如前述，則上訴人主張其得依民法第250條及系爭契約闡明條款第10條規定 ，請求被上訴人給付遲延罰款，應非無據。

（二）被上訴人雖抗辯上訴人因洛克希德公司已完成部分工作，上訴人並因此受有利益，依最高法院 49年台上字第807號判例意旨，本件違約金應予酌減云云。按當事人約定契約不履行之違約金過高者， 法院固得依民法第252條以職權減至相當之數額，惟是否相當仍須依一般客觀事實、社會經濟狀況及當事人所受損害情形，以為酌定標準，而債務已為一部履行者，亦得比照債權人所受利益減少其數額（最高法院49年台上字第807號判例參照）。 是債務人已為一部履行而得減少其違約金數額者，以債權人因其一部履行而受有利益為其要件。本件洛克希德公司雖已完成TACC之PDR、CDR及TCC之PDR，及部分硬體之安裝，惟系爭航管自動化系統係由多數軟、硬體設備，逐層組裝、連結、測試而成，經由系統各部分相互作用而達航管自動化之目的，各單項部分單獨發生之效用於航管之自動化無甚助益，本件航管自動化系統於契約終止時，軟體之設計及硬體之架設既均未完成，並無法於航管自動化發生任何效用，已難認上訴人就已完成之部分受有何利益。而觀諸上訴人於契約終止後，並未依闡明條款第5.3.1.條c款約定， 要求洛克希德公司交付任何供應品或製造材料，且終止契約後洛克希德公司於系爭航管自動化工程所使用之部品材料，即置放現場無人加以利用，上訴人亦未於洛克希德公司已完成之TACC之PDR、CDR及TCC PDR基礎上， 另行發展航管自動化系統，上訴人主張其未就洛克希德公司已履行部分，獲有利益，尚堪信取。

（三）又查系爭航管自動化系統為我國航空發展之重要計畫，民航局因洛克希德公司執行航空自動化系統工程之進度緩慢，未能依履行交付航空自動化系統之義務，使民航局雖花費眾多人力資力，其航空管制自動化工程未能依預定計畫完成，而需另行向第三人採購，致延宕多年，所受損害不可謂不重。衡諸本件之客觀事實、社會經濟狀況及上訴人所受損害情形，及洛克希德公司如能如期履行債務時，上訴人可享受之一切利益等一切情狀，本件契約闡明條款第10條約定以各系統每逾一日以該系統契約價款萬分之五計算違約金，尚屬相當，並無過高。被上訴人抗辯契約約定之違約金過高，應予酌減，並無可採。

（四）被上訴人雖又抗辯自 77年1月15日洛克希德公司提出完工計畫至 77年6月25日上訴人終止契約止之遲延，乃可歸責於民航局所致，此期間應不計入遲延罰款之期間云云。惟本件契約闡明條款第5.3.1條a款規定民航局因洛克希德公司無法在規定期限內履行，而欲終止契約時，應先於60天前通知洛克希德公司，若洛克希德公司未能於60天內提出適當之補救計畫，民航局即得終止契約，是適當補救計畫之提出乃洛克希德公司於經民航局通知後，可以避免契約被終止，所應採取之措施，非謂洛克希德公司提出補救計畫後，即可不負遲延責任。且單純提出補救計畫，並無法治癒洛克希德公司給付遲延之狀態，而原可歸責於洛克希德公司之遲延既仍繼續存在，即非可認係可歸責於民航局之事由而遲延，況洛克希德公司所提完工計畫並非適當之補救措施，已如前述。被上訴人抗辯洛克希德公司提出完工計畫後即不負遲延責任，於洛克希德公司提出完工計畫後其遲延即屬可歸責於民航局，委無足取。

（五）查系爭契約於簽訂後，迭經修正，將完工期限變更為：㈠TACC系統為76年8月30日、㈡台北TCC系統為76年11月30日、㈢高雄TCC系統為77年2月29日、㈣台中TCC系統為 77年5月30日，惟迄至77年6月25日契約終止時，洛克希德公司並未完成上開任何一項系統， 又無闡明條款第4.1條及第

4.2條第1項各款所定可調整展延完工期限之情事，履行契約已有遲延，已如前述。則自76年8月31日算至77年6月25日契約終止時， 洛克希德公司就TACC系統部分共遲延300日；自76年12月1日算至77年6月25日契約終止時，洛克希德公司就台北TCC系統共遲延208日；自77年3月1日算至77年6月25日契約終止時，洛克希德公司就高雄TCC系統共遲延117日；自77年5月31日算至77年6月25日契約終止時，洛克希德公司就台中CC系統共遲延26日。惟依契約闡明條款第10條之約定各系統之遲延罰款不得超過該系統契約價款之百分之六，以每日以系統契約價款萬分之五計算，即計算各系統之遲延罰款以120日為上限（6%÷0.05%＝120）。又系爭契約於76年9月10日第六次修正時，將契約總價修正為美金3904萬4071元，其中美金付款部分為美金3166萬7184元，新台幣付款部分為新台幣2億9684萬5974元， 又修正後TACC系統部分之價款為1184萬7,000美元及新台幣7288萬1623元， 修正後台北TCC系統部分之價款為661萬2000美元及新台幣4063萬4717元，修正後高雄TCC系統部分之價款為481萬2000美元及新台幣2957萬468元，修正後台中TCC系統部分之價款為446萬5000美元及新台幣2744萬4050元，有第六次契約修正文件在卷可稽（見原審原證卷第一冊第11至33頁）。則依此計算，洛克希德公司之遲延罰款TACC系統部分為美金71萬0820美元、新台幣437萬2887元，台北TCC系統部分為美金69萬6720美元、新台幣243萬8083元，高雄TCC系統部分為美金28萬1502美元、新台幣172萬9842元，台中TCC系統部分為美金5萬8045美元、新台幣35萬6722.65元，合計美金144萬7087美元、新台幣889萬7625.43元（詳如附表三）。

（六）惟按民法第217條第1項規定，損害之發生或擴大，被害人與有過失者，法院得減輕賠償金額或免除之。此項規定之適用，原不以侵權行為之法定損害賠償請求權為限，即契約所定之損害賠償，除有反對之特約外，於計算賠償金額時亦難謂無其適用（最高法院54年台上字第2433號判例參照）。洛克希德公司履行本件航空自動化系統工程之遲延，經中科院依各工程項目重要權重比，及締約雙方應負擔之加權責任數計算民航局應負擔之13.4%之責任， 洛克希德公司應負擔86.6%之責任， 有中科院鑑定報告在卷可稽（見外鑑定報告第2頁） ，則依此計算，上訴人可請求之遲延罰款計為美金1,253,177.34美元（1,447,087×86.6%＝1,253,177.34）、新台幣7,705,343.62元（8,897,625.43×86.6%＝7,705,343.62）。 又雖另案成大航太所鑑定報告認民航局應負擔之責任比為43.33%，惟查系爭航管自動化系統工程龐大複雜，且涉及航空、資訊、系統整合等多項專業領域，另案成大航太所之鑑定報告係由成大航太系教授林清一負責鑑定（參鑑定報告第2頁），而中科院之鑑定報告係由中科院成立專案編組，納編航管經驗、戰管經驗、專案管理、系統工程、法律專業與採購案履約專業人員組成鑑定專案小組，由各種專業領域之成員、專家參與討論、研判（見本院卷四第43頁、卷九第41頁），顯較能整合航空、資訊、系統整合等各方面專業知識及經驗為研判，且中科院之鑑定報告就各個鑑定項目，均詳細說明其鑑定結果所依據之證據資料及相關之專業理論及實務，較之成大航太所之鑑定報告，應認中科院之鑑定報告為詳實可採，併此敘明。

十二、上訴人可否依民法第227條、第231條、第233條、第179條、第184條、第176條，及國外採購契約條款第20條規定，請求被上訴人賠償其所支付之關稅、信用狀保證及簽證費？及其數額？

（一）按終止契約，僅使契約自終止之時起向將來消滅，並無溯及效力，當事人原已依約行使、履行之權利義務不受影響。 又民法第260條規定解除權之行使不妨害損害賠償之請求，此項規定於當事人依法律之規定終止契約者，依同法第263條規定，固得準用之。 惟所指之損害賠償，並非積極的認有新賠償請求權發生，不過規定因其他原因已發生之賠償請求權，不因之行使而受妨礙。故因契約消滅所發生之損害，不在民法第260條所定得請求賠償之列 （最高法院88年台上字第1219號、84年台上字第1931號判決意旨參照）。

（二）上訴人主張其因系爭航空自動化契約，共支付關稅新台幣91,121,951元，信用狀保證及簽證費新台幣4,515,097元，固據其提出海關進口貨物各項稅款收入繳納證、進口結匯手續費收據、開狀手續費、簽證費收據等為證（見原審原證卷第一冊第64至103頁）。惟查系爭契約闡明條款第3條約定：「In accordance with the RFP SupplementalProcurement Document, Note 28,all customs duties,harbour fees, airport fees and othe import fees

and taxes for all equipment and spars parts will

be brone by CAA. This shall also apply to LECtools and test equipment described under clause 1herein.（依「招標補充採購文件」附註28之規定，一切設備及而備用零件之全部關稅、港埠費、機場費及進口規費與稅捐均由民航局負擔。 本規定於闡明條款第1條所述洛克希德電子公司之工具及測試設備，亦有適用）」，另中信局購料處國外採購合約條款（Conditions ofContract）第6條規定：「Payment for the suppliesunder this Contract, unless otherwise specified,shall be made to the Seller by an irrevocableLetter of Credit (L/C) in favor of the L/C Bene-ficiary named by the Seller in his bid, and allbanking charges incurred outside the Republic ofChina under the L/C shall be borned by the L/CBeneficiary or the Seller.（除另有規定外，本合約付款方以不撤銷信用狀為之，信用狀受益人由賣方指定並載明於其報價單上，有關信用狀之銀行費用，其在中華民國境外發生者，概由信用狀受益人或賣方負擔。）」，則上訴人支出之進口關稅、稅捐與於國內發生之信用狀保證及簽證費，均屬系爭契約約定應由上訴人負擔之費用，上訴人支出上開費用非無法律上之原因。又系爭契約雖因洛克希德公司給付遲延而經上訴人終止，惟終止契約，僅使契約自終止之時起向將來消滅，並無溯及效力，當事人原已依約行使、履行之權利義務不受影響，則上訴人依約定支付上開費用，核係履行契約約定之義務，難謂係因洛克希德公司債務不履行所生之損害，且其既因履行契約上之義務而為給付，亦難認係為洛克希德公司管理事務，另上訴人亦未舉證並主張洛克希德公司就此有為如何不法之侵害，則其主張洛克希德公司應依民法第227條、第231條、第233條、第179條、第184條、第176條規定賠償其所支付之關稅、信用狀保證及簽證費，並無足取。

（三）另中信局購料處國外採購合約第20條規定「In case anysupplies are rejected within the guarenteed period, the Seller, upon receipt of CTC's notice, shalldespatch repleacement(s) at hte earliest possibledate, Such additional costs asinsurance, freight,charges,fees,duties and other relevant expensesinvolved inshipment of the replacement(s) ans re-jected supplies shall be borne by the Seller But

the rejected supplies shall not be shipped back to

the port of origin until the replacement is ac-cepted by CTC or its client. In the case CTC re-ject any defective or nonconforming supplies anddoes not require replacement(s), or in case theSeller fails to make a replacement shipment withinthree months after receiving CTC's notice, theSeller shall refundto CTC such portion of the Con-tract price of the supplies as in equitable in thecircumstances. In case CTC accepts the defetive ornoncomforming or a part thereof with a claim forcompensation, the Seller shall pay CTC such com-pensation within one month after receivinig CTC'snotice; otherwise, CTC will collect the compensa-tion from the performance bond.If,upon collectionfrom the performance bond, there is still anydefference due to CTC,the Seller is liable fotsettlement of the compensation.（在保證期間內如有退貨情形發生，售方應於收到本處通知後，儘速換貨。因換貨及退貨所需之一切費用，包括保險費、海運費、進口稅捐及其他費用概由售方負擔；退還之物品，應俟售方辦妥換貨並經買方接受後始得運回。凡不符或有瑕疵貨品不需換貨者，或售方到本處通知後三個月內未辦妥換貨者，售方應依當時公平合理條件，退還價款。又本處同意由售方賠款以接受不符或有瑕疵貨品者，售方應於收到通知後一個月內繳付賠款，否則本處將自履行保證金內扣抵，如有不足，仍應由售方負責理楚）」，係就換貨退貨所為之規定，非關於契約終止後雙方權利義務之規定，上訴人主張其可依中信局購料處國外採購合約第20條規定，請求洛克希德公司賠償其所支付之關稅、信用狀保證及簽證費，亦無可取。

十三、綜上，上訴人得依不當得利法律關係請求返還頭期款美金354萬9,590.25美元、新台幣3,400萬1,100元， 及器材款美金476萬879.27美元； 另得依闡明條款第10條規定請求給付遲延罰款美金125萬3,177.34美元及新台幣770萬5,34

3.62元，合計美金956萬3,646.86美元（計算式：3,549,

590.25＋4,760,879.27＋1,253,177.34＝9,563,646.86美元）、新台幣4,170萬6,444元（計算式：34,001,100＋7,705,343.62＝41,706,444新台幣，元以下四捨五入）。

陸、綜上所述，被上訴人洛克希德飛機公司未能於契約約定期限依約交付TACC系統， 且無闡明條款4.1條、第4.2條第1項各款所定可調整或逐日順延完工期限之情形，又未能於接受上訴人通知後六個月內提出適當的補救措施，上訴人自得依闡明條款第5.3.1.a條終止契約， 請求返還已付未完成部分之價金及遲延罰款，被上訴人洛克希德馬汀公司合併前之美商洛克希德公司為洛克希德飛機公司之連帶保證人，並應與洛克希德飛機公司負連帶責任。惟洛克希德飛機公司於契約終止前已完成TACC系統之PDR、CDR及TCC系統之PDR，此部分之報酬上訴人不可請求返還，且上訴人對於洛克希德飛機公司之履行遲延應負13.4%之責任， 應依比率減少其遲延罰款。

而按給付無確定期限者，債務人於債權人得請求給付時，經其催告而未為給付，自受催告時起負遲延責任。又遲延之債務，以支付金錢為標的者，債權人得請求依法定利率計算之遲延利息。應付利息之債務，其利率未經約定，亦無法律可據者，週年利率為百分之五 。民法第229條第2項、第233條、第203條定有明文。而被上訴人洛克希德飛機公司於78年8月10日收受起訴狀繕本，被上訴人洛克希德馬汀公司合併前之美商洛克希德公司於 79年2月27日收受起訴狀繕本，有送達證書在卷可稽（見原審卷一第43、87頁）。從而，上訴人台灣銀行依民法第179條、闡明條款第10條約定，請求被上訴人連帶給付美金956萬3,646.86美元、新台幣4,170萬6,444元，及均自起訴狀繕本送達翌日 （即被上訴人洛克希德飛機公司自78年8月11日起 、被上訴人洛克希德馬汀公司自79年2月28日起） ，均自清償日止按年息百分之五計算之利息部分，為有理由，應予准許。逾此所為請求，為無理由，應予駁回。又，上訴人台灣銀行勝訴部分，兩造分別陳明願供擔保為准、免假執行之宣告，經核於法並無不合，爰分別酌定相當擔保金額准許之。至於上訴人台灣銀行敗訴部分，其假執行之聲請失所附麗，應併予駁回。原審就上開應准許部分，為上訴人台灣銀行敗訴之判決，並駁回其假執行之聲請，尚有未洽，上訴人台灣銀行上訴意旨求為廢棄改判，為有理由，爰由本院予以廢棄改判如主文第二項所示，並為准、免假執行之宣告。至於上訴人之請求不應准許部分，原判決為上訴人台灣銀行敗訴之判決，並駁回其假執行之聲請，經核於法並無不合，上訴人台灣銀行上訴意旨求予廢棄改判，為無理由，應駁回其上訴。又主觀訴之合併，先位之訴有理由，為備位之訴之解除條件，先位之訴無理由，為備位之訴之停止條件，本件上訴人台灣銀行合併前之中信局及備位上訴人民航局，均為系爭契約之當事人，就系爭契約有相同之權利義務，就系爭契約對於契約相對人可請求之範圍亦均相同，本件上訴人台灣銀行之訴既部分有理由，即無庸就備位上訴人之訴為審究，併此敘明。

柒、本件事證已臻明確，兩造其餘之攻擊防禦方法及所提證據，經審酌後認均無礙判決之結果，爰不予一一論述。

捌、據上論結，本件上訴為一部有理由，一部無理由，依民事訴訟法第450條、第449條第1項、第79條、第85條第2項、第463條、第390條第2項、第392條第2項，判決如主文。中 華 民 國 100 年 12 月 20 日

民事第三庭

審判長法 官 林敬修

法 官 劉勝吉法 官 張靜女正本係照原本作成。

如不服本判決，應於收受送達後20日內向本院提出上訴書狀，其未表明上訴理由者，應於提出上訴後20日內向本院補提理由書狀（均須按他造當事人之人數附繕本）上訴時應提出委任律師或具有律師資格之人之委任狀；委任有律師資格者，另應附具律師資格證書及釋明委任人與受任人有民事訴訟法第466條之1第1項但書或第2項（詳附註）所定關係之釋明文書影本。如委任律師提起上訴者，應一併繳納上訴審裁判費。

中 華 民 國 100 年 12 月 22 日

書記官 蕭麗珍附註：

民事訴訟法第466條之1（第1項、第2項）：

對於第二審判決上訴，上訴人應委任律師為訴訟代理人。但上訴人或其他法定代理人具有律師資格者，不在此限。

上訴人之配偶、三親等內之血親、二親等內之姻親，或上訴人為法人、中央或地方機關時，其所屬專任人員具有律師資格並經法院認為適當者，亦得為第三審訴訟代理人。