1、某地鐵工程電力監(jiān)控與環(huán)控集成系統(tǒng)投標文件 目 錄 TOC o 1-3 h z u HYPERLINK l _Toc112831618 1. 前言 PAGEREF _Toc112831618 h 1 HYPERLINK l _Toc112831619 2. 組織分解結構（OBS） PAGEREF _Toc112831619 h 1 HYPERLINK l _Toc112831620 2.1. 組織的目標 PAGEREF _Toc112831620 h 1 HYPERLINK l _Toc112831621 2.2. 項目治理打算 PAGEREF _Toc112831621 h 2 HYPERLI

2、NK l _Toc112831622 3. 工作分解結構（WBS） PAGEREF _Toc112831622 h 3 HYPERLINK l _Toc112831623 3.1. 和合作投標伙伴工作分工 PAGEREF _Toc112831623 h 4 HYPERLINK l _Toc112831624 3.2. 分時期描述 PAGEREF _Toc112831624 h 4 HYPERLINK l _Toc112831625 3.2.1. 系統(tǒng)和接口設計 PAGEREF _Toc112831625 h 4 HYPERLINK l _Toc112831626 3.2.2. 軟/硬件開發(fā)，制

3、造與采購 PAGEREF _Toc112831626 h 9 HYPERLINK l _Toc112831627 3.2.3. 在工廠中集成檢驗/測試 PAGEREF _Toc112831627 h 10 HYPERLINK l _Toc112831628 3.2.4. 工廠驗收檢驗（FAT） PAGEREF _Toc112831628 h 10 HYPERLINK l _Toc112831629 3.2.5. 運輸 PAGEREF _Toc112831629 h 11 HYPERLINK l _Toc112831630 3.2.6. 安裝 PAGEREF _Toc112831630 h 12

4、 HYPERLINK l _Toc112831631 3.2.7. 安裝測試 PAGEREF _Toc112831631 h 12 HYPERLINK l _Toc112831632 3.2.8. 初步驗收 PAGEREF _Toc112831632 h 13 HYPERLINK l _Toc112831633 3.2.9. 功能測試 PAGEREF _Toc112831633 h 13 HYPERLINK l _Toc112831634 3.2.10. 綜合測試（聯(lián)調）和試運行 PAGEREF _Toc112831634 h 13 HYPERLINK l _Toc112831635 3.2.

5、11. 保修 PAGEREF _Toc112831635 h 14 HYPERLINK l _Toc112831636 4. 項目治理 PAGEREF _Toc112831636 h 15 HYPERLINK l _Toc112831637 4.1. 項目打算 PAGEREF _Toc112831637 h 16 HYPERLINK l _Toc112831638 4.2. 工作分配 PAGEREF _Toc112831638 h 16 HYPERLINK l _Toc112831639 4.3. 預算分配和治理 PAGEREF _Toc112831639 h 16 HYPERLINK l _

6、Toc112831640 4.4. 需求與配置治理 PAGEREF _Toc112831640 h 16 HYPERLINK l _Toc112831641 4.4.1. 需求治理 PAGEREF _Toc112831641 h 16 HYPERLINK l _Toc112831642 4.4.2. 系統(tǒng)配置治理 PAGEREF _Toc112831642 h 18 HYPERLINK l _Toc112831643 4.4.3. 軟件配置治理 PAGEREF _Toc112831643 h 18 HYPERLINK l _Toc112831644 4.5. 復查、匯報、會議及審核 PAGER

7、EF _Toc112831644 h 19 HYPERLINK l _Toc112831645 4.5.1. 內(nèi)部月進度審查會 PAGEREF _Toc112831645 h 19 HYPERLINK l _Toc112831646 4.5.2. 內(nèi)部季度預算審查會 PAGEREF _Toc112831646 h 19 HYPERLINK l _Toc112831647 4.5.3. 內(nèi)部進度會 PAGEREF _Toc112831647 h 19 HYPERLINK l _Toc112831648 4.5.4. 項目月進度會 PAGEREF _Toc112831648 h 19 HYPERL

8、INK l _Toc112831649 4.5.5. 時期性審查 PAGEREF _Toc112831649 h 20 HYPERLINK l _Toc112831650 4.5.6. 配置審核 PAGEREF _Toc112831650 h 20 HYPERLINK l _Toc112831651 4.5.7. 質量系統(tǒng)治理審查和預防性措施 PAGEREF _Toc112831651 h 20 HYPERLINK l _Toc112831652 4.6. 協(xié)調與溝通 PAGEREF _Toc112831652 h 20 HYPERLINK l _Toc112831653 4.7. 接口設計打

9、算 PAGEREF _Toc112831653 h 21 HYPERLINK l _Toc112831654 4.7.1. 接口設計 PAGEREF _Toc112831654 h 21 HYPERLINK l _Toc112831655 4.7.2. 溝通與交流 PAGEREF _Toc112831655 h 21 HYPERLINK l _Toc112831656 4.7.3. 接口文件 PAGEREF _Toc112831656 h 22 HYPERLINK l _Toc112831657 4.7.4. 接口變更治理 PAGEREF _Toc112831657 h 25 HYPERLIN

10、K l _Toc112831658 4.7.5. 接口測試 PAGEREF _Toc112831658 h 26 HYPERLINK l _Toc112831659 4.8. 與公共治理部門的協(xié)調 PAGEREF _Toc112831659 h 26 HYPERLINK l _Toc112831660 4.9. 文件操縱 PAGEREF _Toc112831660 h 27 HYPERLINK l _Toc112831661 4.9.1. 規(guī)則與流程 PAGEREF _Toc112831661 h 27 HYPERLINK l _Toc112831662 4.9.2. 文件發(fā)放 PAGEREF

11、 _Toc112831662 h 27 HYPERLINK l _Toc112831663 4.10. 采購和分包合同治理 PAGEREF _Toc112831663 h 28 HYPERLINK l _Toc112831664 4.10.1. 采購 PAGEREF _Toc112831664 h 28 HYPERLINK l _Toc112831665 4.10.2. 分包合同治理 PAGEREF _Toc112831665 h 28 HYPERLINK l _Toc112831666 4.11. 設備交貨后的治理 PAGEREF _Toc112831666 h 28 HYPERLINK l

12、 _Toc112831667 4.12. 現(xiàn)場組織與資源 PAGEREF _Toc112831667 h 28 HYPERLINK l _Toc112831668 4.13. 綜合后備支持 PAGEREF _Toc112831668 h 28 HYPERLINK l _Toc112831669 4.14. 質量治理 PAGEREF _Toc112831669 h 29 HYPERLINK l _Toc112831670 4.15. 風險治理 PAGEREF _Toc112831670 h 29 HYPERLINK l _Toc112831671 4.15.1. 風險治理規(guī)則 PAGEREF _

13、Toc112831671 h 29 HYPERLINK l _Toc112831672 4.15.2. 風險治理活動 PAGEREF _Toc112831672 h 29 HYPERLINK l _Toc112831673 4.15.3. 風險表 PAGEREF _Toc112831673 h 30 HYPERLINK l _Toc112831674 5. 附件1: 工作與組織分解結構 PAGEREF _Toc112831674 h 31 HYPERLINK l _Toc112831675 6. 附件2：風險治理表的格式 PAGEREF _Toc112831675 h 45前言本項目治理打算基

14、于綜合監(jiān)控系統(tǒng)成功的實施經(jīng)驗，和科學的項目治理體系，還借鑒了其它項目如廣州地鐵三、四、五號線綜合監(jiān)控系統(tǒng)項目打算和實際執(zhí)行情況，這關于成功實施*地鐵綜合監(jiān)控系統(tǒng)具有特不重要的意義。項目打算是項目順利實施并保證項目質量的前提，是項目組織開展工作的依據(jù)，同時要適應項目的特點和專門要求。依照用戶需求書，總結該項目具有以下幾個鮮亮的特點：*地鐵綜合監(jiān)控系統(tǒng)工程為國內(nèi)領先的大規(guī)模綜合監(jiān)控系統(tǒng)工程，對成熟的解決方案和綜合技術實施水平的要求較高；采取國外軟件平臺和技術解決方案為主導，國內(nèi)系統(tǒng)集成商提供工程服務的項目實施形式；面對的技術接口數(shù)量與種類較多；工作接口與協(xié)調任務較多；項目工期較為緊張。*公司和合作

15、投標伙伴公司將發(fā)揮各自在軌道交通行業(yè)系統(tǒng)工程實施治理經(jīng)驗，共同制定本文件。本文件的目的是初步闡述*地鐵綜合監(jiān)控系統(tǒng)項目的實施治理思路，要緊包括以下兩方面內(nèi)容：工作范圍和工作分解結構（WBS）；項目治理打算。其中，項目治理打算的基礎是組織分解結構（OBS）和工作分解結構（WBS）。本文件是與組織結構有關的質量打算的一個補充，同時會在項目后期進行必要的修改或修正。組織分解結構（OBS）組織的目標立即參與實施該項目的組織將實現(xiàn)如下目標：在北京設立項目組，以便及時了解和掌握業(yè)主的需求；依靠*公司和合作投標伙伴公司雙方現(xiàn)有的組織和技術，提供最新的、最可靠的系統(tǒng)和優(yōu)質的服務；依照其他綜合監(jiān)控系統(tǒng)項目中差不

16、多成功實施的方案，提供一個通過充分證明的系統(tǒng)。為了實現(xiàn)這三個目標，我們將成立下面的組織：*公司將在北京建立一個（現(xiàn)場）協(xié)調小組，在設計、開發(fā)及制造時期，及時和北京地鐵溝通，了解需求，同時和合作投標伙伴公司接口設計小組一起協(xié)調同接口設備商之間的設計工作。該小組重點工作是加強與項目干系組織之間的信息溝通；在本項目的開發(fā)、制造時期，合作投標伙伴公司將在北京成立一個項目小組，以方便ISCS和接口設備之間接口的設計和協(xié)調；在本項目的現(xiàn)場安裝、集成和測試時期，合作投標伙伴公司將在北京成立一支當?shù)丶夹g和協(xié)調小組（LTCT）。小組將每天與業(yè)主進行協(xié)調并為業(yè)主和合作投標伙伴公司之間的溝通提供便利。該小組將特不關

17、注讓盡可能多的人員利用漢語進行交流。當來自法國的工程師可不能講漢語時，合作投標伙伴公司將成立一些由一位法國和一位中國工程師組成的小組；依靠*公司和合作投標伙伴公司現(xiàn)有的組織分解各種不同的工作，這些不同工作的詳細描述見下文的“工作分解結構（WBS)”一節(jié)。項目組織結構以及每個小組及其成員的任務與責任詳見B13-1 項目治理組織機構。項目治理打算項目治理打算的構成如下所示：組織分解結構（OBS）：提供了項目組織的詳細結構（參見B13-1 項目治理組織機構）；工作范圍和工作分解結構（WBS）：提供*地鐵綜合監(jiān)控系統(tǒng)項目所需的全部工作范圍；工作分配：為不同的項目小組分配工作。WBS的每一項被指定給OB

18、S的至少一個小組；系統(tǒng)配置治理打算：本打算描述了用來治理系統(tǒng)配置的方法與過程。它也涉及“需求治理”的內(nèi)容，以確保適當?shù)刂卫碛脩舻男枨蟛⒋_保所有交付使用的設備和服務都能滿足合同的要求；軟件配置治理打算：本打算用來治理系統(tǒng)配置的方法和過程；協(xié)調和溝通：確定項目團隊內(nèi)部外部之間的信息溝通途徑、方式和方法，如審查、匯報和召開會議；接口治理打算：用來制定并打算接口開發(fā)、測試及協(xié)調的方式、方法等；文件操縱打算：用于文件操縱和發(fā)放的規(guī)則與程序；采購和分包合同治理打算：描述了采購和分包工作的程序；設備交貨治理；現(xiàn)場組織和結構：包括現(xiàn)場辦公室、車間及庫房；綜合后勤支持：包括備用件、專門工具和測試設備、文件、培訓

19、等；質量保證打算：用來確保系統(tǒng)、軟件、硬件、安裝活動以及相關問題的質量的程序與方法；風險治理打算：包括風險識不、評估以及風險預防措施；其他的雜項打算，例如：健康和安全打算以及環(huán)保打算等。工作分解結構（WBS）WBS的目的是對工作項中的活動進行細分，由項目小組或分包商的合格的小組或個人承擔不同的責任。最終的結構形成了一個共同的參考系統(tǒng)，該系統(tǒng)同意將項目各個時期的成本、進度以及責任匯總在一起。具體見“ REF _Ref112768332 h 附件1: 工作與組織分解結構”所示內(nèi)容。WBS中各工作項具有如下特點：能夠由一個小組進行治理；公布的成果能夠依照輸入/輸出標準進行檢查；能夠通過自己與其他工作

20、項的接口來定義；能夠定義開工與完工日期；由項目主管與工作項/小組經(jīng)理共同協(xié)商批準必需的工作量（總工時）和資源。依照現(xiàn)時期可得到的信息，我們總結出下面初步的WBS：治理；系統(tǒng)與接口設計；軟、硬件的開發(fā)、制造/采購；在工廠中的集成與驗證/測試；工廠驗收檢驗（FAT）；現(xiàn)場交貨；安裝；接口測試；培訓；現(xiàn)場驗收（SAT），包括點對點的測試；試運行與初步驗收；保修期或故障保修期與最終驗收。和合作投標伙伴工作分工詳見A10 軟件采購合同。分時期描述系統(tǒng)和接口設計系統(tǒng)及接口設計將分三個時期完成（即，設計時期1、2、3）。在每個時期，*公司和合作投標伙伴公司將完成設計和預備系統(tǒng)及接口設計文件的工作。這些文件將

21、送給業(yè)主或接口系統(tǒng)供應商進行檢查和評審。系統(tǒng)及接口設計文件是：系統(tǒng)需求規(guī)范 （SRS）SRS的要緊目的是按照用戶的需求，*公司和合作投標伙伴公司編制最終的系統(tǒng)規(guī)范，最終版本的系統(tǒng)規(guī)范經(jīng)用戶審核并確認。本文件提供了適合系統(tǒng)特點的要求，并規(guī)定了相關的驗證方法。SRS包含下列信息：系統(tǒng)需求列表；需求的限定方法定義；要求的可追溯性定義；軟件需求規(guī)范（SWRS）和硬件需求規(guī)范（HWRS）。依照軟件和硬件配置項目描述了系統(tǒng)的詳細結構，以及系統(tǒng)不同部分之間的接口和數(shù)據(jù)流情況。它也在各種軟件和硬件配置項目中分配了系統(tǒng)需求。人機界面接口（HMI）設計HMI的要緊目的是定義操作職員作站的圖形用戶界面，包括全部立即

22、應用的人機界面（HMI）設計。HMI詳細資料將在各自的軟件設計規(guī)范（SWDS）中提供。軟件設計規(guī)范（SWDS）SWDS的目的如下所示：解釋軟件要求，并將其用一種功能性、操作員可理解的方式陳述出來；為相關軟件包的初步、詳細設計收集所有的有用信息；操作員相關系統(tǒng)任務的定義；相關系統(tǒng)環(huán)境和由該系統(tǒng)治理的要緊對象的描述；相關系統(tǒng)不同功能的詳細描述；測試打算；需求的可追溯性；降級模式；參考系統(tǒng)的HMI描述。硬件設計規(guī)范（HWDS）HWDS將詳細描述所提供硬件設備的有關內(nèi)容，如制造商和要緊技術特點等，包括：計算機系統(tǒng)及外圍設備；FEP；IBP；網(wǎng)絡設備；大屏幕。詳細的接口規(guī)范（DIS）與其他接口系統(tǒng)（包括

23、通信協(xié)議、I/O點以及進度表）接口的定義。依照經(jīng)驗，為了實現(xiàn)下述目的： 滿足本項目緊迫的施工進度要求；方便10號線以后的系統(tǒng)擴展。建議使用開放、標準的協(xié)議（例如基于TCP/IP的Modbus），在每個設計時期結束時，都會召開設計和接口聯(lián)絡會以便進行討論、決策和設計驗收、檢驗的方式方法。在本項目的設計時期，*公司和合作投標伙伴公司將實施的審查工作，見 REF _Ref133395362 h 表 31：表 STYLEREF 1 s 3 SEQ 表 * ARABIC s 1 1設計時期審查表項目打算ISCS 責任范圍對業(yè)主、設計單位、接口供貨商的約束條件第一次設計聯(lián)絡會啟動第一次設計聯(lián)絡會，所有接口

24、商將參加并討論詳細接口規(guī)范(DIS)。第一次設計聯(lián)絡會的目標如下：理解工程化方法（V字軟件工程實施模型）和質量治理體系、提交文件治理體系；通過項目概念演示，使業(yè)主、設計方能更好地理解ISCS系統(tǒng)；所有與會方討論接口設計，討論并確定接口設計方案（DIS詳細接口規(guī)范、協(xié)議、冗余方案、設備圖符、設備類表點表、測試方案、子系統(tǒng)的相關工程打算、所需資料列表等）并書面簽字（里程碑）。通過DIS將使所有接口商明確實現(xiàn)共同目標所需要的工作列表。依照合同及澄清文件，對用戶需求（UR）進行詳細分析及細化，得到系統(tǒng)需求規(guī)范（SRS）、軟件需求規(guī)范（SWRS）、硬件需求規(guī)范（HWRS）。初步討論并確定圖形用戶界面(H

25、MI)設計原則，包括用戶權限表、設備編序法等等。IBP盤初始設計。HOLLYSYS要求所有與會方遵循設備類表、點表、圖形的版本基線操縱治理方法、變更與修改方法，以期減少不必要的、不符合修改規(guī)范的變更。業(yè)主確認在工程方法、質量系統(tǒng)方面沒有異議；業(yè)主有必要向各接口商及其對應的業(yè)主、設計方，多次強調：各方必須遵循設備類表、點表、圖形的版本基線操縱治理方法、變更與修改方法，以期減少不必要的、不符合修改規(guī)范的變更。 接口設計聯(lián)絡會議的重要先決條件：為了討論接口方案，業(yè)主應在通知并協(xié)調接口會議時接口商。在該方面的任何延遲均會導致項目的延遲；接口商應出席接口聯(lián)絡會議，并在會議期間將其書面意見提交給HOLLY

26、SYS；在會議期間，當接口商同HOLLYSYS之間出現(xiàn)爭議時，由業(yè)主進行調停；設計方、接口商應向ISCS提供設備類表、點表。會議結束時，接口商應簽署接口文件（DIS、協(xié)議、冗余方案、測試方案），并簽署設備類表、點表、圖符的設計文件。業(yè)主應讓設計方、接口商明確工作流程、工作關系、各自職責。業(yè)主對上述設計工作及簽署文件進行確認，并協(xié)助ISCS供應商獲得尚缺少資料。建議業(yè)主安排運營相關骨干人員，直接全程參與設計聯(lián)會及后續(xù)的重要設計會議，以完成需求分析、反饋及評估等重要工作。第二次設計聯(lián)絡會在第二設計時期結束前，將召開第二次設計聯(lián)絡會。第二次設計聯(lián)絡會的目標如下：更新并凍結圖形用戶界面(HMI)設計原

27、則，包括用戶權限表、設備編序法、圖符庫等等。所有與會方更新、凍結并書面簽字：用戶需求（UR）系統(tǒng)需求規(guī)范（SRS）軟件需求規(guī)范（SWRS）硬件需求規(guī)范（HWRS）討論并通過系統(tǒng)設計規(guī)范（SDS），如數(shù)據(jù)流設計等。討論并通過軟件設計規(guī)范（SWDS），如：系統(tǒng)功能設計，如：報警 雪崩 SOC 時刻表 報表 歷史庫、事件 趨勢 用戶權限表 權限治理 圖形原則（設備編序 顏色定義 圖符）計算事件 聯(lián)動功能設計 配置治理 打印治理 在線關心等等。子系統(tǒng)功能設計，包括：PSCADA、 BAS、 PA 、CCTV、 PIS 、TCC的功能設計；接口測試規(guī)范程序文件（ITSP）；NMS DMS TMS的功能設

28、計；討論并凍結硬件設計規(guī)范（HWDS），固化設備的硬件配置，固化IBP設計。提供并討論初版施工圖業(yè)主審核HOLLYSYS提供的所有文檔，并在第二次設計聯(lián)絡會議之前或在會議期間將意見提交給HOLLYSYS。業(yè)主核準所有的系統(tǒng)設計（見左側的責任范圍內(nèi)容）。業(yè)主應完成并完善第二次設計聯(lián)絡會要求的所有的相關工作。接口商應參加均席設計聯(lián)絡會議，并在會議期間將其書面意見提交給HOLLYSYS。接口商應完成第二時期設計聯(lián)絡會要求的相關工作。在會議期間，當接口商同HOLLYSYS之間出現(xiàn)爭議時，由業(yè)主進行調停。業(yè)主應對上述設計工作及簽署文件進行確認，并協(xié)助ISCS供應商獲得尚缺少的資料。通過本次會議，務必最終

29、確定并固化設計方案，確定并固化各接口子系統(tǒng)的設備類表、點表的版本基線。否則,在后續(xù)工作中，過多的變更會大大增加制造時期的返工量，導致項目進度延遲。本次會議所確定的設備類表、點表版本基線，將做為軟件FAT、P2P測試的軟件基礎版本基線。第三次設計聯(lián)絡會在第三時期設計聯(lián)絡結束前，HOLLYSYS將召集第三次設計聯(lián)絡會。第三次設計聯(lián)絡會的目標，是討論并確認如下：明確工程總體及各子系統(tǒng)的打算與調試進度，并倒排ISCS的工程進度打算； 最終版施工出圖：系統(tǒng)圖、材料表網(wǎng)絡連接圖管線圖供電圖、配電圖接地圖IBP結構設計圖、端子圖支架設計圖柜體設計圖車控室布置圖設備房布置圖設備編號講明安裝督導講明等等討論并確

30、定往常設聯(lián)會未盡事宜；回憶工程進度，重申重要原則，評估并預測工程執(zhí)行風險，統(tǒng)一各方思想、工作方式及工作重點。業(yè)主審核HOLLYSYS提供的所有文檔，并在第三次設計聯(lián)絡會議之前或在會議期間將意見提交給HOLLYSYS。業(yè)主應完成并完善往常設計聯(lián)絡會要求的所有的相關工作。在會議期間，當與其它專業(yè)調試進度等與ISCS之間出現(xiàn)爭議時，業(yè)主應進行調停。會議結束時，業(yè)主、設計等與會各方應簽署會議紀要。 軟/硬件開發(fā)，制造與采購軟件開發(fā)本時期與典型軟件部件的實現(xiàn)時期相對應，合作投標伙伴有責任利用這些軟件來構建整個系統(tǒng)。軟件開發(fā)要緊在香港（部分工作在法國）完成，具體包括：人機界面接口（HMI）的模型化、數(shù)據(jù)庫

31、的設計和實現(xiàn)以及測試打算；軟件的初步和詳細設計；編碼和單元測試，包括：時刻表，圖形動畫、窗口和HMI的編碼；數(shù)據(jù)庫配置；接口編碼；具體功能編碼（將保存一份軟件配置表）；軟件集成和集成測試。在本時期一開始，其他的接口設備/系統(tǒng)供應商需提供接口模擬器。與模擬器的初步接口測試將同接口系統(tǒng)/設備供應商一起在北京完成。硬件采購一般來講，該工作包括定義和公布采購本項目所需設備的文件。本時期的目的是：詳細定義需采購的硬件；詳細定義需采購軟件包；采購硬件和軟件包。依照分工，由*公司和合作投標伙伴公司合作完成硬件系統(tǒng)的采購，而由*公司負責相關的安裝及布置設計，*公司和合作投標伙伴共同負責軟件設計，因此*公司和合

32、作投標伙伴公司將時刻保持聯(lián)絡，溝通必要的設備數(shù)據(jù)。依照系統(tǒng)需求，*公司和合作投標伙伴公司將編制并保存硬件配置表。部件測試在進行系統(tǒng)集成和檢驗之前，系統(tǒng)的每項內(nèi)容都將在工廠進行測試。這種測試包括所有項，作為子系統(tǒng)測試中的組成，有使用前的檢查、硬件測試和軟件測試。項目測試證明一個項目滿足了它的特定的物理和功能要求。必要時，能夠進行特定測試。各種工廠制造的電氣裝置要進行檢驗和驗收。對這種硬件的檢驗可能包括：這種設備是否符合制造商規(guī)范；設備是否齊全；正確操作測試；一致性檢查（元件布置圖、配線圖）；協(xié)議測試；冗余測試；點對點檢查；絕緣檢測；檢測接地連續(xù)性。在工廠中集成檢驗/測試在本時期開始，業(yè)主或其代表

33、須確認并批準由*公司和合作投標伙伴公司制定的工廠測試規(guī)范和現(xiàn)場測試規(guī)范。開發(fā)時期會伴隨著一系列的設備和子系統(tǒng)測試。通過進行與接口設備/系統(tǒng)供應商的協(xié)議測試，集成測試同意對硬件/軟件模塊以及它們在適當系統(tǒng)中的集成進行測試。檢驗測試同意按照工廠驗收打算對系統(tǒng)進行測試。這些測試及測試結果會記錄在測試報告中。工廠驗收檢驗（FAT）工廠驗收檢驗的目的是為了驗證在現(xiàn)場配置和安裝前，系統(tǒng)是否與規(guī)范相符。為了進行高效的檢驗，工廠驗收檢驗將分兩個時期進行：第一個時期的FAT將對有代表性的部分進行檢驗。目的是驗證各個部分在進行完全配置和安裝前的功能和性能。第二時期的FAT將對完全配置但未安裝的系統(tǒng)進行檢驗，它將檢

34、驗數(shù)據(jù)庫、圖形界面以及系統(tǒng)的綜合性能。工廠功能驗收測試（FAT）系統(tǒng)中進行工廠驗收的要緊部分是：計算機系統(tǒng)（服務器和工作站）；軟件和參數(shù)設置。它們將在合作投標伙伴的香港工廠中進行單獨的工廠驗收檢驗。測試軟件、硬件與其他接口商提供的系統(tǒng)互連，能夠確保軟硬件與其他系統(tǒng)的兼容性。接口商應提供模擬設備以便進行FAT測試，最后測試將在現(xiàn)場進行。其他硬件設備的FAT在*公司完成。工廠綜合驗收測試 （iFAT）工廠綜合驗收檢驗結合了ISCS系統(tǒng)中的所有項目并模擬那些由其他接口系統(tǒng)/設備供應商提供的部分。利用模擬器、仿真器或真實設備檢查以確保所有接口都正確，同時確保系統(tǒng)的功能是完備的。然后，將系統(tǒng)當成一個整體

35、來測試以證明它滿足了功能、容量、可維護性和可操作性的各方面要求。進行測試以證明項目或整個系統(tǒng)的操作差不多上正確的，測試包括：驗證在整個集成系統(tǒng)、設備和軟件配置中所有應用軟件功能的綜合測試；驗證系統(tǒng)可靠性；與接口系統(tǒng)的協(xié)議測試、冗余測試、點對點測試：在測試時點的覆蓋率達到了100%。運輸依照包裝運輸打算完成包裝、裝卸和運輸程序，將設備運到業(yè)主提供的存儲地或最終安裝地，庫房由業(yè)主提供并治理。*公司當?shù)丶夹g與協(xié)調小組將完成的工作包括：在用戶到場的情況下進行包裝和裝箱檢查；將設備發(fā)運到庫房區(qū)；給設備貼標簽；開包/開箱進行設備檢查。按照裝箱單以及采購文件進行驗收；與安裝小組進行協(xié)調，將設備運往最后的安裝

36、現(xiàn)場。安裝只有在完成土建工程后才能進行設備的現(xiàn)場安裝。如此做能夠確?；覊m可不能進入設備的內(nèi)部、可不能引起嚴峻的硬件損害。ISCS必須安裝在潔凈、有空調設備的房間中。*公司和合作投標伙伴公司將派遣安裝督導小組在北京以監(jiān)督、指導安裝過程。安裝工作由業(yè)主完成。這包括現(xiàn)場電纜敷設安裝以及所有的硬件設備的物理安裝。操縱系統(tǒng)計算機和FEP硬件安裝在最終位置上，并與必要的、通過測試過的線纜連接在一起。依照*公司和合作投標伙伴公司或其他供貨商提供的安裝手冊并在業(yè)主批準的情況下進行設備安裝。安裝手冊包括：安裝打算；安裝圖紙（布置圖、電纜表、單元接線圖等）；施工圖；安裝程序；安裝督導指導書（詳細描述設備安裝的技術

37、要點）。電纜安裝過程由業(yè)主安裝隊完成電纜的安裝。安裝工作的時刻順序如下所示：安裝用于電纜敷設（電纜托架、電纜愛護套管以及電纜管道）的輔助設備；敷設電纜；電纜聯(lián)接/電纜終端處理；初步檢查（導通性及絕緣檢查，等等）。安裝人員安裝人員由業(yè)主組織，可分成若干個小組，每個小組有一個負責人，負責治理和協(xié)調工作。安裝打算將有條件地與下面的合同保持協(xié)調：土建工程；配電專業(yè)（為綜合監(jiān)控系統(tǒng)提供電源）；通過FEP采集數(shù)據(jù)的各子系統(tǒng)。為了按打算好的施工進度表完成施工，依照業(yè)主批準的物理接口進度表安裝人員將同意在安裝工作的每一步與接口工作人員進行協(xié)調。安裝測試安裝測試小組由*公司硬件安裝經(jīng)理、督導工程師和分包商相關人

38、員組成。硬件設備的安裝測試在現(xiàn)場完工后進行，這包含如下所示的步驟：初步檢查；功能測試；試運行。安裝測試按照安裝測試手冊進行。安裝測試手冊包括：初步檢查程序；功能測試程序；試運行程序。初步驗收在設備安裝結束時，將對系統(tǒng)的機械和電源部分做初步檢查和測試工作。這包括：目視檢查是否與批準的圖紙相符；是否符合質量標準；檢查電纜連接完整性、標簽與型號；檢查設備標簽；對設備進行點對點檢查，以檢查是否與接線圖一致；接地和電源檢測。這項檢測應該在裝配完工后進行。將檢測情況記錄在完整的檢測報告中。這些檢測應該在通電的情況下進行。功能測試包括每個設備的有效試運行。它們將在初步檢查結束后進行。按照地鐵系統(tǒng)中的其他設備

39、的情況預先確定好檢測程序。這些檢測包括：邏輯自動系統(tǒng)的檢驗；驗證是否與規(guī)定的要求相符；檢驗交付給用戶使用的備用件。測試程序的基礎是工廠驗收檢驗。當所有由其他的接口系統(tǒng)/設備供應商提供和安裝的子系統(tǒng)都運行工作后，再進行功能測試。綜合測試（聯(lián)調）和試運行這包括整個系統(tǒng)的有效試運行同時這些測試將在功能測試完成后進行。為了讓整個合同系統(tǒng)投入運行，這些測試的順序與由其他接口系統(tǒng)/設備供應商實施的系統(tǒng)測試保持一致。綜合測試和試運行包括：綜合測試，包括測試其他接口系統(tǒng)/設備供應商的專門應用；端到端的功能測試以檢查數(shù)據(jù)交換情況；每個接口與其他接口系統(tǒng)/設備供應商工作之間的通信和有效數(shù)據(jù)傳送的功能測試；故障模擬

40、；響應時刻測量；系統(tǒng)與其他接口系統(tǒng)/設備供應商設備的集成測試；144小時穩(wěn)定性測試；3個月的試運行。試運行的結束使*公司能夠向用戶證明項目差不多成功完工。試運行期間進行的測試能夠證明該系統(tǒng)是完全可交付使用的，這是測試的最后時期。在完成測試規(guī)范中所規(guī)定的測試項目后，再公布測試結果。保修保修期為2年，包括：硬件保修；軟件保修。在保修期內(nèi)解決問題的程序以*公司提供并經(jīng)用戶批準的故障通知單或用戶請求電話、傳真為基礎。用戶請求電話或傳真通知*公司的現(xiàn)場技術與協(xié)調人員，或由用戶的維修代表填寫表格，用來記錄由用戶發(fā)覺的故障，并將表格遞交給*公司的現(xiàn)場技術與協(xié)調人員，以便*公司及時采取相應的保修措施。硬件保修

41、來自*公司的硬件保修代表或用戶的維修人員對現(xiàn)場硬件進行檢查以便確認故障是否存在。將由*公司的現(xiàn)場技術與協(xié)調人員或用戶的維修人員鑒不并除掉有故障的硬件。業(yè)主將把故障部件遞交給*公司以便進行維修/更換新部件。在故障排除后，業(yè)主的維修代表會簽署故障通知并解決該問題。軟件保修軟件保修包括電話技術支持以及修正軟件的任意缺陷。這種保修將由合作投標伙伴的保修代表現(xiàn)場進行。軟件保修代表必須對故障進行鑒定，同時能夠要求用戶到場進行調查以便確定故障情況。假如認為故障屬于異常情況，則軟件小組將預備修正軟件，需要時還會更新相關的文件。在用戶到場的情況下，在測試平臺上進行的這種修正是有效的。一旦進行了修正，就要填寫軟件

42、異常修正表。由用戶確認該修正工作并批準該表格。項目治理項目治理活動包括以下16個方面：項目打算和商業(yè)/合同治理；工作分配：為工作包或小組經(jīng)理定義工作對象/范圍；預算分配和預算治理；要求和配置治理；通過報告、會議、復查進行進度監(jiān)控（包括協(xié)調并向用戶匯報）；協(xié)調和溝通；接口治理；與政府部門/治理當局的協(xié)調；文件操縱；采購和分包商治理；設備交貨后的治理；工地組織和結構；綜合后勤支持；培訓治理；質量治理；風險治理。下面將詳細描述項目治理的16個方面：項目打算*公司將制定總體項目打算，具體由項目打算與合同治理組完成。下列文件提供了詳細的項目打算：設計和制造打算；軟件開發(fā)打算；安裝測試打算。合作投標伙伴將

43、在軟件開發(fā)、安裝測試方面單獨制定詳細打算，并提交*公司，*公司形成總體打算送交業(yè)主。工作分配目的是為不同的項目小組分配工作。依照工作分工，*公司和合作投標伙伴公司將分不制定各自的WBS，WBS的每項工作都被分配給OBS的至少一個小組。每位小組經(jīng)理對自己小組的工作結果負責，并向項目經(jīng)理/主管匯報工作。因此每位小組經(jīng)理都必須對分配給自己小組成員的工作以及他/她的工作范圍的任務負責。關于人力資源，每個小組必須明確自己的需要以便能夠獨立處理自己工作范圍內(nèi)的工作。假如要增加資源，小組經(jīng)理必須向項目經(jīng)理/主管請示。預算分配和治理項目經(jīng)理分配給每一位小組經(jīng)理一份預算以便其完成自己的工作。成本治理員定期跟蹤小

44、組經(jīng)理的預算以更新他們的預算狀況。每位小組經(jīng)理都必須考慮在合適的技術和組織選擇方面分配其預算。每三個月要求每位小組經(jīng)理向成本治理員提供一份包含如下內(nèi)容的預測報告：完成工作所需的資源；未付費用/采購費。然后，成本治理員會更新預測的工作預算。在超支的情況下，小組經(jīng)理必須向項目治理小組提供一份恢復打算。為了滿足用戶的進度的要求，進度要求的滿足將優(yōu)先成本方面的考慮，立即不計較成本，首先滿足進度要求。需求與配置治理需求治理需求治理是開發(fā)綜合監(jiān)控系統(tǒng)軟件，完成綜合監(jiān)控系統(tǒng)工程的一個要緊的組成部分。下面幾節(jié)的目的在于提供差不多定義好的特不是軟件功能需求方面的一般規(guī)則，并描述組織結構情況以便具備一個有效的需求

45、治理系統(tǒng)。該項任務由*公司和合作投標伙伴公司共同完成，治理工具將由合作投標伙伴提供。一般規(guī)則DOORS套裝軟件是一套公認的軟件包，它用于治理復雜系統(tǒng)的需求同時差不多被合作投標伙伴集團采納。合作投標伙伴集團差不多開發(fā)了一個應用層并將其與DOORS集成在一起。這一應用層被稱為TREK。為了用一種精確、有效的方法跟蹤合同的要求，THALES集團差不多決定在整個項目期間使用DOORS/TREK軟件包作為需求治理工具。一般過程一般過程如下所述：將用戶所有的技術要求輸入到DOORS；將系統(tǒng)需求規(guī)范（SRS）的系統(tǒng)要求輸入到DOORS模塊中去；將詳細的接口規(guī)范（DIS）的要求輸入到DOORS模塊中去；將上述

46、SRS和DIS中包含的需求分配給DOORS模塊中被稱作系統(tǒng)設計規(guī)范（SDS）的工作分解項，該項列在工作分解結構中。這些配置項目，既包含硬件配置項（HWCI）又包含軟件配置項目（CSCI）；依照系統(tǒng)需求以及SRS和DIS中規(guī)定的要求，將DOORS模塊中的CSCI和HWCI撰寫為軟件需求規(guī)范（SWRS）和硬件需求規(guī)范（HWRS）；將CSCI和HWCI的要求分配給工作分解結構DOORS模塊中被稱作軟件設計規(guī)范（SWDS）和硬件設計規(guī)范（HWDS）的配置項目；給對應于上述細分結構的不同層次的測試定義集成、驗證和確認（IVV）模塊；關于變化跟蹤來講，不管是出于什么緣故 （用戶、設計約束、技術最優(yōu)化的建議

47、） 引起的所有的技術變化都由工程變更操縱系統(tǒng)治理。需求治理組織由于需求治理系統(tǒng)專門用于技術需求，因此它由系統(tǒng)工程經(jīng)理和系統(tǒng)與集成小組負責。DOORS工具的治理由系統(tǒng)配置工程師執(zhí)行。系統(tǒng)配置治理配置治理打算中規(guī)定了整個項目期間都要遵循的與系統(tǒng)配置治理有關的規(guī)則。當項目治理打算和配置治理打算之間發(fā)生沖突時，將按照下面的優(yōu)先次序執(zhí)行：1.項目治理打算；2.配置治理打算。為了能夠依照清晰設計而開發(fā)系統(tǒng)，及為了擁有一套一致的文件和DOORS模塊，將定期更正系統(tǒng)基準。在整個項目期間，該過程都會進行。配置操縱委員會（CCB）將負責在整個項目周期中定義各種基準。系統(tǒng)配置工程師將負責跟蹤并監(jiān)督將投入使用的基準系

48、統(tǒng)。將遵循的一般規(guī)則如下所示：在給定的參考系中，系統(tǒng)基準與一套基準的DOORS模塊對應；對應于給定基準的文件將儲存在DOORS模塊中；將有兩類基準：正式基準：它們對應一套模塊包括基準和正式提交給用戶的基準；非正式基準：它們對應一套于DOORS模塊的基準，但未包含在正式提交給用戶的基準。不管是什么緣故要求變更文件，都必須向負責確認并決定何時執(zhí)行變更的CCB提交一份變更建議：在CCB做出正式?jīng)Q定之前，任何人都不能擅自變更作為基準的模塊；當CCB做出執(zhí)行變更的決定時，變更及其相關阻礙將輸入到DOORS中去。進行變更后，所有修改過的文件都必須進行基準變更，同時系統(tǒng)基準也必須進行相應地變動；正式文件基準

49、按照文件的修訂版進行命名；非正式文件基準按照正式最新的修訂版參考號并后加一個字母命名；正式系統(tǒng)基準的名稱由字母“S”后接199的數(shù)字構成；非正式系統(tǒng)基準由字母“S”后接199的數(shù)字以及一個小寫字母構成；為了檢查是否正確執(zhí)行了變更情況，必須使用一個跟蹤系統(tǒng)。這種監(jiān)督工作由系統(tǒng)配置工程師負責；在項目的任何時期，任何活動都必須按照目前批準的系統(tǒng)基準進行。軟件配置治理軟件配置治理打算中規(guī)定了軟件配置治理的規(guī)則和程序。在配置治理打算和軟件配置治理打算發(fā)生沖突時，將按照下面的優(yōu)先順序執(zhí)行：1.配置治理打算；2.軟件配置治理打算。復查、匯報、會議及審核除了設計聯(lián)絡會，將執(zhí)行下面的復查、匯報、會議和審核：內(nèi)部

50、月進度審查會合作投標伙伴項目主管每月通過月項目審查會向*公司項目經(jīng)理匯報工作。*公司和合作投標伙伴公司每位小組經(jīng)理都必須在審查會之前至少一周向各自的項目主管提供與其工作有關的信息以便進行匯總。成本治理員負責將各種報告匯總到審查會報告中去，以便項目經(jīng)理在審查會前進行分析。成本治理員負責組織這些會議并通知相關的與會人員。內(nèi)部季度預算審查會項目主管通過季度預算審查會每年向法國的項目部主管和成本治理員匯報4次工作。每位小組經(jīng)理在季度預算審查會前至少3周向項目經(jīng)理提供與其工作有關的預算信息用于信息匯總。成本治理員負責將各種數(shù)據(jù)匯總到項目季度預算審查會中去，以便項目經(jīng)理在季度預算審查會前進行分析。成本治理

51、員負責組織這些會議并通知相關與會人員。內(nèi)部進度會*公司和合作投標伙伴公司每周將各進行一次公司內(nèi)部進度會。所有的小組經(jīng)理都必須參加。關于某些會議來講，可能會邀請額外的項目小組成員參加。這些會議將在每周一下午4點進行。如遇公共假期，則會議自動順延至第二天的同一時刻進行。如遇專門情況，會議能夠延期進行。項目月進度會*公司和合作投標伙伴公司每月進行月進度會，該會議是*公司和合作投標伙伴公司基于項目治理層面，小組經(jīng)理也參加會議。關于某些會議，可能會邀請額外的項目小組成員參加。這些會議由*公司組織并主持。關于相關的每月進度報告：將在每月5號提交；每位小組經(jīng)理都必須填寫部分與其工作范圍相關的報告；秘書負責組

52、織收集各種報告并將其編入每月進度報告。必須在每月5號前至少兩天將報告草案提交給項目經(jīng)理批閱。時期性審查在項目施工期間，在每個重要時期結束時都要進行內(nèi)部審查，內(nèi)容包括：系統(tǒng)設計審查（SDR）：目的是審查詳細接口規(guī)范（DIS）、系統(tǒng)需求規(guī)范（SRS）、系統(tǒng)設計規(guī)范（SDS，包括SWDS和HWDS）以及接口需求規(guī)范（IRS）；部件設計復查（CDR）：目的是檢查各子系統(tǒng)和系統(tǒng)組成部分的設計文件是否適合生產(chǎn)；系統(tǒng)測試預備就緒復查（STRR）：目的是檢查與系統(tǒng)測試相關的文件是否同意在工廠進行系統(tǒng)測試以及在現(xiàn)場以一種操縱方式進行系統(tǒng)測試。配置審核配置審核能夠用來驗證系統(tǒng)和配置項目與其基準是否相符。質量系統(tǒng)治

53、理審查和預防性措施*公司和合作投標伙伴公司將審查本項目中執(zhí)行的質量系統(tǒng)的適宜性和有效性。由打算經(jīng)理預備預防性措施分析報告以分析內(nèi)部審核、用戶審核和日常操作中發(fā)覺的非一致性問題。然后將在每年至少進行一次的質量系統(tǒng)的治理復查會上批閱預防性措施分析報告。質量系統(tǒng)的治理復查會將由項目主管主持，與會人員包括質量工程師、系統(tǒng)工程經(jīng)理以及由會議主席確定的其他特不與會人員。流程包括：配置治理流程；質量系統(tǒng)改進和操縱流程；質量保證流程；預防性措施流程。協(xié)調與溝通項目信息的溝通在綜合監(jiān)控系統(tǒng)項目內(nèi)顯得特不重要，不僅是在團隊內(nèi)部各職能小組之間需要進行及時的溝通聯(lián)絡，同時該項目的一個突出特點差不多決定了該項目需要大量

54、的接口協(xié)調工作，即*公司需要同若干個項目組織之間建立通暢的信息溝通渠道和高效信息溝通流程，這關于保證綜合監(jiān)控系統(tǒng)項目的順利進行和高質量的完成都具有重要的意義。該項目治理將重點關注項目的溝通治理，將配合業(yè)主和監(jiān)理建立一套基于該項目各相關組織之間的溝通打算。*地鐵綜合監(jiān)控系統(tǒng)項目將需要與以下各方進行強有力的協(xié)調與頻繁聯(lián)絡：北京地鐵公司（包含ISCS業(yè)主及其它專業(yè)業(yè)主）；工程監(jiān)理；設計院；土建承包商；安裝承包商；其他的接口系統(tǒng)/設備供應商。為了有效實現(xiàn)這種協(xié)調，在設計和開發(fā)時期，工作人員將在香港和北京工作，在現(xiàn)場安裝/接口/測試時期以及保修期內(nèi)其工作人員將在北京工作。協(xié)調活動包括兩類：接口設計；現(xiàn)場

55、協(xié)調。接口設計打算關于順利完成像*地鐵綜合監(jiān)控系統(tǒng)如此的工程，接口治理是一個特不重要的問題。關于項目開發(fā)來講，接口治理活動是要緊的信息來源之一，同時在整個工程期間它都需要與其他各方進行強有力的協(xié)調。本接口治理打算（IMP）定義了用來開發(fā)ISCS和接口系統(tǒng)之間詳細接口要求的治理過程。本打算的目的是為無縫集成提供方便，使其符合ISCS用戶需求以及接口設備規(guī)范。此外，IMP將提出*公司和合作投標伙伴公司與接口承包商用來定義兩個系統(tǒng)間接口的詳細要求的過程。接口治理將在接口文件中提出下面的屬性：電氣、機械、軟件協(xié)議以及功能數(shù)據(jù)接口；檢查、測試和試運行。文件也將定義進行資源治理、文件變動操縱、*公司和接口

56、承包商之間溝通以及沖突解決所需的過程。接口設計在投標書的B10-2系統(tǒng)接口詳細建議書中給出了詳細的接口規(guī)范要求。溝通與交流接口會議接口會議的工作范圍如下所示：了解各方的設計要求，開發(fā)并協(xié)商通過設計和接口要求以滿足北京地鐵合同中所規(guī)定的要求；確定阻礙接口設計的關鍵性能參數(shù)和問題；確定設計時期、安裝時期以及試運行時期的測試要求細節(jié)；按照每個合同中的總規(guī)劃協(xié)商通過設計和測試程序；協(xié)商提交給北京地鐵的接口文件。接口會議的時刻及地點安排將由接口雙方協(xié)商。我們建議能夠在北京進行接口會議。承包商之間的信息交流承包商之間通過圖紙和講明性文件這兩種方法進行信息交流。能夠在接口會議期間或者通過正式公文交流信息。通

57、過圖紙交流的信息包括結構圖、機械詳圖、電器詳圖、接口電路圖、接線圖等等。講明性文件用來描述程序、系統(tǒng)特點、電器特點、測試要求以及會議記錄，包括行動表。雙方利用電子郵件、傳真或電話經(jīng)常保持溝通以明確設計和所有后勤安排的細節(jié)。達成的協(xié)議將在接口會議后形成會議紀要或正式的可公布文件。需要業(yè)主的支持雙方在接口會議期間通過正式文件解決問題。當確認問題需要北京地鐵介入時，雙方或者在接口會議的紀要中或者通過書面通知業(yè)主。當無法就關鍵問題達成協(xié)議或者對各方合同中的專門需求或接口規(guī)范要求的解釋持不同意見時，將趕忙以書面形式向業(yè)主發(fā)出仲裁和確認請求。業(yè)主出席會議將加速問題的解決。接口文件將為每位接口承包商預備下列

58、文件：詳細的接口規(guī)范（DIS）文件的目的目的是規(guī)定并描述與ISCS和接口系統(tǒng)間接口相關的所有信息；由于在系統(tǒng)設計時期不可能獵取所有的信息，本文件將在項目進行期間不斷進行修正。文件治理和提交DIS是一種ISCS文件同時由*公司和合作投標伙伴公司制作和治理。在向業(yè)主公布前，將由接口承包商復查本文件。我們建議與其他的接口承包商正式簽署DIS文件；接口承包商也能夠將DIS用于自己的接口文件。我們建議使用沒有改動過的文件，同時建議加上一個封皮，使接口承包商文件在參考上與接口承包商規(guī)范保持一致；兩個封面的重疊將表明文件修訂版是如何與雙方的合同保持同步的。典型的文件格式見 REF _Ref112659927

59、 h 表 41表 STYLEREF 1 s 4 SEQ 表 * ARABIC s 1 1典型文件格式組成部分內(nèi)容1. 目的本部分應敘述有關的接口及兩個合同參考2. 參考文件本部分將涉及ISCS規(guī)范的相關部分和附錄。本部分也包括參考標準或其他的應用文獻。3. 術語表任何使用過的首字母縮寫詞的含義。解釋相關或必要的詞匯或技術用語。4. 接口規(guī)范4.1 接口圖接口圖中指出了工作范圍和責任范圍。4.2 物理接口4.2.1 特性和位置一張表表明每個接口的特性和準確位置。位置可能是車站、車輛段、OCC（操縱中心）或一座輔助建筑物內(nèi)的一個房間。4.2.2 電氣描述本部分包括一張原理圖，圖中標明了成分、電纜以

60、及接線安排的電壓、電流或阻抗規(guī)格以及電源規(guī)格。4.2.3 機械描述本部分包括： -端子柜編組原則； -機柜尺寸和安裝； -接線柱、插座和接線端子。4.3 功能接口本部分的目的是提供兩方面的要求了解。接口設備及其監(jiān)控數(shù)據(jù)和功能將按照ISCS和接口商的最初合同要求列出來。4.4 協(xié)議本部分將提供用于接口的詳細軟件協(xié)議。4.5 命名慣例本部分將講明用來識不ISCS和接口系統(tǒng)中的每種信息的命名慣例。命名慣例將用來識不ISCS工作站中的信息和為設備、電纜以及接線端子加標簽。4.6 設計約束條件本部分將列出所有的設計約束條件，例如，專門響應時刻、通信軟件版本，等等。4.7 EMC（電磁兼容性）假如存在，則