Page 232 - 捷運工程叢書 精進版 － 30 捷運機電系統管理與界面整合實務

臺北市政府捷運工程局

契約需求 系統操作計畫
緊急救援計畫
項目需求分配表 系統
PRAT ICD 定義 子系統功能清單 整合
審查
審查 CDR、DDR、 其他文件
PRAT FDR 測試 系統功能定義 (SFS)

系統需求定義 (SRS)
系統整合測試

系統復原分析 (SRA)

圖 13-2-1 臺中綠線系統整合流程圖

13.2.3 N 平方圖

13.2.3 N 平方圖
界面的處理分成兩個主要階段：
一、定義（identification）階段
界面的處理分成兩個主要階段：
定義各個子系統間有哪些界面存在，並且儘量設法定義各個子系統間的基本的配合關係。
一、定義（identification）階段：
在定義的階段所要建立的工作就是一組清單，定義界面有哪些項目，在這方面最常使用
定義各個子系統間有哪些界面存在，並且儘量設法定義各個子系統間的基本的配合關係。
的工具稱為N平方圖（N-Square Chart）（Reilly, 1993: 111）。例如以「行車監控、供電、通訊」
在定義的階段所要建立的工作就是一組清單，定義界面有哪些項目，在這方面最常使用
三個子系統為例，可以定出其 N 平方圖如圖 13-2-2 所示。由圖 13-2-2 中可知這三個子系統
的工具稱為 N 平方圖（N-Square Chart）（Reilly, 1993: 111）。例如以「行車監控、供電、
共有 6 種界面要定義：
通訊」三個子系統為例，可以定出其 N 平方圖如圖 13-2-2 所示。由圖 13-1 中可知這三個子
( 一 ) 車輛對行車監控的界面 A 及行車監控對車輛的界面 D。
系統共有 6 種界面要定義：
(一)車輛對行車監控的界面 A 及行車監控對車輛的界面 D。
( 二 ) 車輛對通訊的界面 B 及通訊對車輛的界面 E。
(二)車輛對通訊的界面 B 及通訊對車輛的界面 E。
( 三 ) 行車監控對通訊的界面 C 及通訊對行車監控的界面 F。
(三)行車監控對通訊的界面 C 及通訊對行車監控的界面 F。

車輛 行車監控 通訊

車輛 A B

行車監控 D C

通訊 E F

圖 13-2-2 車輛、行車監控、通訊的 N 平方圖
圖 13-2-2 車輛、行車監控、通訊的 N 平方圖
二、執行（implementation）階段：
針對每一個界面進行協調及確認並建立文件。

13.2.4 界面管制文件

當 N 平方圖定義完成後，接下來要做的就是每個界面的實際執行，這個工作通常就是每
216 217
種界面的每個項目透過一份「界面管制文件」來確認。但是由於界面關係是對偶的，因此所
要簽認的界面管制文件會只剩一半，重點在於決定由哪個子系統發出界面管制文件（主導者）
給對方（配合者）。當牽涉到 3 個以上的子系統時，也要指定一個主導者，其他子系統則為配

合者。另外，實務上最好能有一套編號系統來為每一個界面項目及其相關的界面管制文件賦
與編號。
界面管制文件在一般的教科書和參考書籍中都寫成「Interface Control Document」並

且簡稱為「ICD」（例如 Reilly（1992）的第 9 章、Grady，1994：207 及 Blanchard，1998：
224）。

第三節 發展沿革

臺北捷運建設是在總顧問第二期契約期間，由總顧問引進界面管制文件制度，經過第三
處及機電系統工程處的學習、內化，在中和線、土城線轉移到統包廠商；最近完工通車的環

185