倉儲運輸及安裝調試方案

項目組織施工驗收方案、設備安裝、調試方案項目進度控制計劃項目管理計劃涉及以下15個方面：項目計劃和商業(yè)/協(xié)議管理；工作分派：為工作包或項目副經(jīng)理定義工作對象/范圍；預算分派和預算管理；規(guī)定和配置管理；通過報告、會議、復查進行進度監(jiān)控（涉及協(xié)調并向用戶報告）；協(xié)調和溝通；接口管理；與政府部門/管理當局的協(xié)調；文獻控制；采購和分包商管理；設備交貨后的管理；工地組織和結構；綜合后勤支持；質量管理；風險管理。下面將具體描述項目管理的15個方面：項目計劃北京和利時公司將制定總體項目計劃，具體由項目計劃與協(xié)議管理組完畢。下列文獻提供了具體的項目計劃：設計和制造計劃；軟件開發(fā)計劃；安裝測試計劃。工作分派目的是為不同的項目小組分派工作。根據(jù)工作分工，北京和利時公司制定項目的WBS（工作分解結構）文獻，WBS的每項工作都被分派給OBS的至少一個小組。每位項目副經(jīng)理對自己小組的工作結果負責，并向項目經(jīng)理/主管報告工作。因此每位項目副經(jīng)理都必須對分派給自己小組成員的工作以及他/她的工作范圍的任務負責。關于人力資源，每個小組必須明確自己的需要以便可以獨立解決自己工作范圍內的工作。假如要增長資源，項目副經(jīng)理必須向項目經(jīng)理/主管請示。本文的“附件一”給出了北京地鐵十四號線基本的WBS。預算分派和管理項目經(jīng)理分派給每一位項目副經(jīng)理一份預算以便其完畢自己的工作。成本管理員定期跟蹤項目副經(jīng)理的預算以更新他們的預算狀況。每位項目副經(jīng)理都必須考慮在合適的技術和組織選擇方面分派其預算。每三個月規(guī)定每位項目副經(jīng)理向成本管理員提供一份包含如下內容的預測報告：完畢工作所需的資源；未付費用/采購費。然后，成本管理員會更新預測的工作預算。在超支的情況下，項目副經(jīng)理必須向項目管理小組提供一份恢復計劃。為了滿足用戶的進度的規(guī)定，進度規(guī)定的滿足將優(yōu)先成本方面的考慮，即將不計較成本，一方面滿足進度規(guī)定。需求與配置管理需求管理需求管理是開發(fā)綜合監(jiān)控系統(tǒng)軟件，完畢綜合監(jiān)控系統(tǒng)工程的一個重要的組成部分。下面幾節(jié)的目的在于提供已經(jīng)定義好的特別是軟件功能需求方面的一般規(guī)則，并描述組織結構情況以便具有一個有效的需求管理系統(tǒng)。一般規(guī)則DOORS套裝軟件是一套公認的軟件包，它用于管理復雜系統(tǒng)的需求并且已經(jīng)被北京和利時公司采用。北京和利時公司已經(jīng)開發(fā)了一個應用層并將其與DOORS集成在一起，并在深圳地鐵2號線和深圳地鐵4號線成功應用此需求管理軟件。為了用一種精確、有效的方法跟蹤本協(xié)議的規(guī)定，北京和利時公司已經(jīng)決定在整個十四號線項目期間使用DOORS軟件包作為需求管理工具。一般過程一般過程如下所述：將用戶所有的技術規(guī)定輸入到DOORS；將系統(tǒng)需求規(guī)范（SRS）的系統(tǒng)規(guī)定輸入到DOORS模塊中去；將具體的接口規(guī)范（DIS）的規(guī)定輸入到DOORS模塊中去；將上述SRS和DIS中包含的需求分派給DOORS模塊中被稱作系統(tǒng)設計規(guī)范（SDS）的工作分解項，該項列在工作分解結構中。這些配置項目，既包含硬件配置項（HWCI）又包含軟件配置項目（CSCI）；根據(jù)系統(tǒng)需求以及SRS和DIS中規(guī)定的規(guī)定，將DOORS模塊中的CSCI和HWCI撰寫為軟件需求規(guī)范（SWRS）和硬件需求規(guī)范（HWRS）；將CSCI和HWCI的規(guī)定分派給工作分解結構DOORS模塊中被稱作軟件設計規(guī)范（SWDS）和硬件設計規(guī)范（HWDS）的配置項目；給相應于上述細分結構的不同層次的測試定義集成、驗證和確認（IVV）模塊；對于變化跟蹤來說，無論是出于什么因素（用戶、設計約束、技術最優(yōu)化的建議）引起的所有的技術變化都由工程變更控制系統(tǒng)管理。需求管理組織由于需求管理系統(tǒng)專門用于技術需求，因此它由系統(tǒng)工程經(jīng)理和系統(tǒng)與集成小組負責。DOORS工具的管理由系統(tǒng)配置工程師執(zhí)行。系統(tǒng)配置管理配置管理計劃中規(guī)定了整個項目期間都要遵循的與系統(tǒng)配置管理有關的規(guī)則。當項目管理計劃和配置管理計劃之間發(fā)生沖突時，將按照下面的優(yōu)先順序執(zhí)行：項目管理計劃；配置管理計劃。為了可以根據(jù)清楚設計而開發(fā)系統(tǒng)，及為了擁有一套一致的文獻和DOORS模塊，將定期更正系統(tǒng)基準。在整個項目期間，該過程都會進行。配置控制委員會（CCB）將負責在整個項目周期中定義各種基準。系統(tǒng)配置工程師將負責跟蹤并監(jiān)督將投入使用的基準系統(tǒng)。將遵循的一般規(guī)則如下所示：在給定的參考系中，系統(tǒng)基準與一套基準的DOORS模塊相應；相應于給定基準的文獻將儲存在DOORS模塊中；將有兩類基準：正式基準：它們相應一套模塊涉及基準和正式提交給用戶的基準；非正式基準：它們相應一套于DOORS模塊的基準，但未包含在正式提交給用戶的基準。無論是什么因素規(guī)定變更文獻，都必須向負責確認并決定何時執(zhí)行變更的CCB提交一份變更建議：在CCB做出正式?jīng)Q定之前，任何人都不能擅自變更作為基準的模塊；當CCB做出執(zhí)行變更的決定期，變更及其相關影響將輸入到DOORS中去。進行變更后，所有修改過的文獻都必須進行基準變更，并且系統(tǒng)基準也必須進行相應地變動；正式文獻基準按照文獻的修訂版進行命名；非正式文獻基準按照正式最新的修訂版參考號并后加一個字母命名；正式系統(tǒng)基準的名稱由字母“S”后接1~99的數(shù)字構成；非正式系統(tǒng)基準由字母“S”后接1~99的數(shù)字以及一個小寫字母構成；為了檢查是否對的執(zhí)行了變更情況，必須使用一個跟蹤系統(tǒng)。這種監(jiān)督工作由系統(tǒng)配置工程師負責；在項目的任何階段，任何活動都必須按照目前批準的系統(tǒng)基準進行。軟件配置管理軟件配置管理計劃中規(guī)定了軟件配置管理的規(guī)則和程序。在配置管理計劃和軟件配置管理計劃發(fā)生沖突時，將按照下面的優(yōu)先順序執(zhí)行：配置管理計劃；軟件配置管理計劃。復查、報告、會議及審核除了設計聯(lián)絡會，將執(zhí)行下面的復查、報告、會議和審核：內部月進度審查會項目經(jīng)理每月通過月項目審查會向項目管理部主管報告工作。每位項目副經(jīng)理都必須在審查會之前至少一周向項目經(jīng)理提供與其工作有關的信息以便進行匯總。成本管理員負責將各種報告匯總到審查會報告中去，以便項目經(jīng)理在審查會前進行分析。成本管理員負責組織這些會議并告知相關的與會人員。內部季度預算審查會項目經(jīng)理通過季度預算審查會每年向項目管理部主管和成本管理員報告4次工作。每位項目副經(jīng)理在季度預算審查會前至少3周向項目經(jīng)理提供與其工作有關的預算信息用于信息匯總。成本管理員負責將各種數(shù)據(jù)匯總到項目季度預算審查會中去，以便項目經(jīng)理在季度預算審查會前進行分析。成本管理員負責組織這些會議并告知相關與會人員。內部進度會北京和利時公司每周將各舉行一次公司內部進度會。所有的項目副經(jīng)理都必須參與。對于某些會議來說，也許會邀請額外的項目小組成員參與。這些會議將在每周一下午4點舉行。如遇公共假期，則會議自動順延至第二天的同一時間舉行。如遇特殊情況，會議可以延期舉行。項目月進度會北京和利時公司每月舉行月進度會，該會議是北京和利時公司基于項目管理層面，項目副經(jīng)理也參與會議。對于某些會議，也許會邀請額外的項目小組成員參與。這些會議由項目經(jīng)理組織并主持。對于相關的每月進度報告：將在每月5號提交；每位項目副經(jīng)理都必須填寫部分與其工作范圍相關的報告；秘書負責組織收集各種報告并將其編入每月進度報告。必須在每月5號前至少兩天將報告草案提交給項目經(jīng)理審閱。階段性審查在項目施工期間，在每個重要階段結束時都要進行內部審查，內容涉及：系統(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)管理審查和防止性措施北京和利時公司將審查本項目中執(zhí)行的質量系統(tǒng)的適宜性和有效性。由計劃經(jīng)理準備防止性措施分析報告以分析內部審核、用戶審核和平常操作中發(fā)現(xiàn)的非一致性問題。然后將在每年至少舉行一次的質量系統(tǒng)的管理復查會上審閱防止性措施分析報告。質量系統(tǒng)的管理復查會將由項目管理部主管主持，與會人員涉及質量工程師、系統(tǒng)工程經(jīng)理以及由會議主席擬定的其他特別與會人員。流程涉及：配置管理流程；質量系統(tǒng)改善和控制流程；質量保證流程；防止性措施流程。協(xié)調與溝通項目信息的溝通在綜合監(jiān)控系統(tǒng)項目內顯得非常重要，不僅是在團隊內部各職能小組之間需要進行及時的溝通聯(lián)絡，同時該項目的一個突出特點已經(jīng)決定了該項目需要大量的接口協(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)場安裝/接口/測試階段以及保修期內其工作人員將在北京工作。協(xié)調活動涉及兩類：接口設計；現(xiàn)場協(xié)調。接口設計計劃對于順利完畢像北京地鐵十四號線綜合監(jiān)控系統(tǒng)這樣的工程，接口管理是一個非常重要的問題。對于項目開發(fā)來說，接口管理活動是重要的信息來源之一，并且在整個工程期間它都需要與其他各方進行強有力的協(xié)調。本接口管理計劃（IMP）定義了用來開發(fā)ISCS和接口系統(tǒng)之間具體接口規(guī)定的管理過程。本計劃的目的是為無縫集成提供方便，使其符合ISCS用戶需求以及接口設備規(guī)范。此外，IMP將提出北京和利時公司與接口承包商用來定義兩個系統(tǒng)間接口的具體規(guī)定的過程。接口管理將在接口文獻中提出下面的屬性：電氣、機械、軟件協(xié)議以及功能數(shù)據(jù)接口；檢查、測試和試運營。文獻也將定義進行資源管理、文獻變動控制、北京和利時公司和接口承包商之間溝通以及沖突解決所需的過程。接口設計具體的接口設計參見《B2-2綜合監(jiān)控專用技術冊（下）》中的論述。溝通與交流接口會議接口會議的工作范圍如下所示：了解各方的設計規(guī)定，開發(fā)并協(xié)商通過設計和接口規(guī)定以滿足北京地鐵協(xié)議中所規(guī)定的規(guī)定；擬定影響接口設計的關鍵性能參數(shù)和問題；擬定設計階段、安裝階段以及試運營階段的測試規(guī)定細節(jié)；按照每個協(xié)議中的總規(guī)劃協(xié)商通過設計和測試程序；協(xié)商提交給北京地鐵的接口文獻。接口會議的時間及地點安排將由接口雙方協(xié)商。我們建議在北京舉行接口會議。承包商之間的信息交流承包商之間通過圖紙和說明性文獻這兩種方法進行信息交流?？梢栽诮涌跁h期間或者通過正式公文交流信息。通過圖紙交流的信息涉及結構圖、機械詳圖、電器詳圖、接口電路圖、接線圖等等。說明性文獻用來描述程序、系統(tǒng)特點、電器特點、測試規(guī)定以及會議記錄，涉及行動表。雙方運用電子郵件、傳真或電話經(jīng)常保持溝通以明確設計和所有后勤安排的細節(jié)。達成的協(xié)議將在接口會議后形成會議紀要或正式的可發(fā)布文獻。需要業(yè)主的支持雙方在接口會議期間通過正式文獻解決問題。當確認問題需要北京地鐵介入時，雙方或者在接口會議的紀要中或者通過書面告知業(yè)主。當無法就關鍵問題達成協(xié)議或者對各方協(xié)議中的特殊需求或接口規(guī)范規(guī)定的解釋持不批準見時，將立刻以書面形式向業(yè)主發(fā)出仲裁和確認請求。業(yè)主出席會議將加速問題的解決。接口文獻將為每位接口承包商準備下列文獻：具體的接口規(guī)范（DIS）文獻的目的目的是規(guī)定并描述與ISCS和接口系統(tǒng)間接口相關的所有信息；由于在系統(tǒng)設計階段不也許獲取所有的信息，本文獻將在項目進行期間不斷進行修正。文獻管理和提交DIS是一種ISCS文獻，由北京和利時公司制作和管理。在向業(yè)主發(fā)布前，將由接口承包商復查本文獻。我們建議與其他的接口承包商正式簽署DIS文獻；接口承包商也可以將DIS用于自己的接口文獻。我們建議使用沒有改動過的文獻，并且建議加上一個封皮，使接口承包商文獻在參考上與接口承包商規(guī)范保持一致；兩個封面的重疊將表白文獻修訂版是如何與雙方的協(xié)議保持同步的。典型的文獻格式見REF_Ref\h表31表STYLEREF1\s3SEQ表\*ARABIC\s11典型文獻格式組成部分內容1.目的本部分應敘述有關的接口及兩個協(xié)議參考2.參考文獻本部分將涉及ISCS規(guī)范的相關部分和附錄。本部分也涉及參考標準或其他的應用文獻。3.術語表任何使用過的首字母縮寫詞的含義。解釋相關或必要的詞匯或技術用語。4.接口規(guī)范4.1接口圖接口圖中指出了工作范圍和責任范圍。4.2物理接口4.2.1特性和位置一張表表白每個接口的特性和準確位置。位置也許是車站、車輛段、OCC（控制中心）或一座輔助建筑物內的一個房間。4.2.2電氣描述本部分涉及一張原理圖，圖中標明了成分、電纜以及接線安排的電壓、電流或阻抗規(guī)格以及電源規(guī)格。4.2.3機械描述本部分涉及：-端子柜編組原則；-機柜尺寸和安裝；-接線柱、插座和接線端子。4.3功能接口本部分的目的是提供兩方面的規(guī)定了解。接口設備及其監(jiān)控數(shù)據(jù)和功能將按照ISCS和接口商的最初協(xié)議規(guī)定列出來。4.4協(xié)議本部分將提供用于接口的具體軟件協(xié)議。4.5命名慣例本部分將說明用來辨認ISCS和接口系統(tǒng)中的每種信息的命名慣例。命名慣例將用來辨認ISCS工作站中的信息和為設備、電纜以及接線端子加標簽。4.6設計約束條件本部分將列出所有的設計約束條件，例如，特殊響應時間、通信軟件版本，等等。4.7EMC（電磁兼容性）假如存在，則本部分將說明所有的電磁兼容性的約束或問題。5.執(zhí)行和安裝本部分將涉及所有的執(zhí)行和安裝事件（假如存在）。5.1限制條件本部分的目的是盡早發(fā)現(xiàn)實行或安裝方面存在的限制：空間規(guī)定、接入日期和特殊工具，等等。假如限制條件影響接口實行和安裝程序，則該限制條件將包含在實行和安裝程序中。假如需要特別關注，則一個限制將被當作是一個特殊的接口問題。5.2程序本部分將提供一個接口實行和安裝程序，該程序至少應當包含兩位承包商所提供的信息和他們根據(jù)各自的目的開工和竣工日期所采用的行動。6.質量保證6.1接口規(guī)定參考本部分是一個基本的互相參照表，它為DIS中所規(guī)定的每條規(guī)定提供了它們相應最初的規(guī)范規(guī)定。6.2驗證和確認本部分是一個基本的表格，它為DIS中所規(guī)定的每條規(guī)定提供了驗證方法。附錄和圖紙具體的數(shù)據(jù)接口附錄對于每個接口位置來說，具體的數(shù)據(jù)接口表涉及：信息標記符（設備和數(shù)據(jù)）；信息描述（設備狀態(tài)）；相應值；點或信息位置（例如在一張表中列出）及地址。電纜、接線端子和圖紙本附錄涉及所有的電纜路由選擇、電纜終端、配置、機柜安排、結構規(guī)定以及空間規(guī)定和電路圖。系統(tǒng)啟動參數(shù)具體的接口測試計劃（DITP）文獻的目的本文獻的目的是定義并描述如何在設計階段實現(xiàn)接口測試，以達成如下目的：一方面，確認計劃的測試是否必要和充足；另一方面，組織單獨測試，然后與接口承包商一起組織聯(lián)合測試。文獻管理和提交DITP是一種ISCS文獻，由北京和利時公司制作和管理；在提交給業(yè)主之前，將由接口承包商審查本文獻；我們建議接口承包商也可以將DITP用于自己的接口文獻。我們建議接口承包商使用沒有改動過的文獻，并且建議加上一個封皮帶有與接口承包商規(guī)范保持一致；兩個封面的重疊將表白文獻的修訂版是如何與雙方的協(xié)議保持同步的。文獻內容見REF_Ref\h表32表STYLEREF1\s3SEQ表\*ARABIC\s12文獻內容組成部分內容1.目的本部分應敘述有關的接口及兩個協(xié)議參考。2.參考文獻本部分將參考ISCS規(guī)范的相關部分和附錄。本部分也涉及參考標準或其他的應用文獻。3.術語表任何使用過的首字母縮寫詞的含義。解釋相關或必要的詞匯或技術用語。4.測試方法本部分將描述在工廠測試階段和現(xiàn)場測試階段如何測試接口，并強調每個階段接口測試的重疊部分。5.接口測試規(guī)范本部分將為工廠和現(xiàn)場測試總結出建議測試程序。5.1測試標記符對于每一種測試，都將分派一個測試標記符。5.1.1測試的目的簡要描述測試的目的。5.1.2需求參考本部分將參考本程序所驗證的接口規(guī)定。5.1.3測試配置本部分描述了完畢測試所必需的硬件和軟件配置。5.1.4測試設備本部分列出了所有必需的測試設備及他們個別的用途。5.1.5測試程序本部分涉及用于相關的測試表的典型格式。6.測試的邏輯順序本部分描述了完畢測試的邏輯順序。7.質量保證7.1接口規(guī)定參考本部分是一個基本的互相參照表，它為DIS中的每條規(guī)定提供了它們相應最初的規(guī)范規(guī)定。附錄&圖紙接口測試規(guī)范程序（ITSP）文獻目的每個ITSP是一種測試程序，它描述了工廠接口測試、現(xiàn)場接口測試、現(xiàn)場端到端測試期間完畢的每項測試；在系統(tǒng)驗收期間，測試程序將被ISCS工程師和接口承包商的工程師用作驗收檢查程序。文獻管理和提交ITSP是一個ISCS和接口承包商的共同文獻。它將由ISCS和接口承包商共同制作、復查并向其各自的工程師發(fā)布；本文獻將被兩位承包商同時參照，以管理它們各自的文獻參考系統(tǒng)。接口測試程序的內容測試的所有細節(jié)、先決條件、測試行動以及預期的測試效果都將編入本文獻。測試表將在測試期間使用和填寫。因此，相關的測試表將由北京和利時公司和其他的承包商簽署并編入測試報告。接口文獻的版本控制文獻版本控制將在每位承包商制定好質量程序之后進行。該文本文獻涉及一張變動控制和署名頁以辨認以前版本的變動情況。文本中可用下劃線來辨認復查過程中的具體變動。在新版本中添加了工具條以表白變動情況。接口變更管理接口設計變更過程在項目周期中，也許有變更接口規(guī)定以改善設計、改正錯誤并最小化風險。接口設計變更過程保證：所有建議的用于接口規(guī)定的硬件、軟件或文獻變更都必須報告、記錄、跟蹤并解決；用一種清楚、一致的方式提出變更說明書；全面評估變更建議并接受對的的解決方案；可以看到所有變更狀態(tài)；并且所有的傳達和傳達途徑都進行了很好的定義。將由ISCS和接口承包商共同制定具體接口規(guī)范。在批準DIS時，將對接口設計（設計凍結）進行基準化。在最初提交后，進行的任何變更都將按接口變更過程執(zhí)行。接口需求變更報告接口需求變更報告是為重要接口問題或異?，F(xiàn)象而編制的文獻。問題也許會與接口需求的任何一方有關。接口變更報告也許會使用一種標準形式、用一種簡潔的方式提出主題：提供問題的描述并證明對的的變更建議。接口需求變更報告將提出所有的相關事實以指出變更的重要性，例如所規(guī)定變更的細節(jié)、假如不變更的風險、建議的應用以及建議的優(yōu)先水平等。接口需求變更報告應當表白設計變更建議是否與規(guī)范規(guī)定和安全規(guī)定相符。接口需求變更報告也應當辨認對的設計變更是否偏離了這些規(guī)定。承包商將決定是否需要召開會議。變更建議的審查接口需求變更報告將由業(yè)主和兩位承包商共商復查以保證它描述了實際的問題并且附上到了所有相關的數(shù)據(jù)。業(yè)主和承包商之間的正式、非正式文獻將闡明或完畢對所提出數(shù)據(jù)的理解。假如有必要召開會議來討論變更建議，那么在也許的情況下將在會議上把眾多的變更建議進行討論。假如復查過程做出了變更結論，則將規(guī)定最初的承包商返工。業(yè)主和承包商在復查過程中規(guī)定的內部安全和系統(tǒng)設計復查將按照它們各自的管理程序進行。變更將通過與會的授權代表復查并記錄于會議紀要中。接口測試為保證ISCS與各系統(tǒng)間接口的對的性，北京和利時公司采用不限于以下內容的測試方法檢查系統(tǒng)間接口是否滿足協(xié)議需求及相關技術規(guī)范。技術規(guī)定檢查方法物理接口負責連接ISCS與各系統(tǒng)目視檢查，冗余測試，通訊測試功能接口ISCS與各系統(tǒng)之間實現(xiàn)的具體功能點對點測試，端對端測試，功能測試，性能測試協(xié)議ISCS與各系統(tǒng)之間通訊采用的具體協(xié)議協(xié)議測試數(shù)據(jù)接口各系統(tǒng)向ISCS提供的信息點點對點測試，端對端測試檢查及確認目視檢查為保證ISCS與各系統(tǒng)承包商提供的接口滿足用戶需求，可以采用目視檢查或尺寸測量的方法進行檢查，不需要專用的儀器設備，對各承包商提供的接口應進行100%的目視檢查以保證接口安裝的對的性。目視檢查測試的重要對象是所有物理接口的連接電纜及接口設備（涉及：電纜安裝、端子排布置，轉換器的安裝位置等），目視檢查將參照DIS中規(guī)定的ISCS與各系統(tǒng)接口劃分及工藝圖紙中來執(zhí)行，目視檢查不涉及電纜的連接電氣測試，該測試應當在安裝階段完畢。目視檢查遵循以下環(huán)節(jié)：ISCS人員核對所有電纜是否已經(jīng)在接口點處安裝就緒，并且是否選擇了最恰當?shù)姆笤O路線。ISCS人員核對所有電纜連接的對的性。通訊測試通訊測試保證各系統(tǒng)設備不同模塊之間能正常通訊，測試將在現(xiàn)場進行。通訊測試的目的是保證所有物理接口的兩端通過電氣連接測試，保證ISCS和各系統(tǒng)兩端可以建立通訊連接。通訊測試涉及以下環(huán)節(jié)：ISCS人員使用萬用表作為測試工具，測試接口雙方的電氣連接。ISCS人員將便攜機連接到ISCSFEP（該便攜機可以監(jiān)視局域網(wǎng)數(shù)據(jù)和連接狀態(tài)）。ISCS人員通過便攜機檢查連接狀態(tài)。協(xié)議測試通訊協(xié)議的測試目的是檢查接口軟件功能，保證ISCS和各系統(tǒng)承包商雙方開發(fā)的協(xié)議及通訊機制達成設計規(guī)范；同時檢查軟件接口部分是否遵守協(xié)議文獻，并澄清在協(xié)議文本中沒有描述清楚的內容。協(xié)議測試應至少包含對所有命令和數(shù)據(jù)的格式、收發(fā)的機制和例外解決等的測試。協(xié)議的測試應通過實際設備進行，除非北京地鐵允許，一般不建議采用模擬器進行協(xié)議測試。在具體接口規(guī)范中描述的接口協(xié)議被認可的情況下，ISCS和各系統(tǒng)應當履行協(xié)議測試，保證承包商雙方正的確現(xiàn)接口協(xié)議，并澄清協(xié)議文獻中未作規(guī)定的問題。協(xié)議測試將測試以下功能：系統(tǒng)初始化消息格式的對的性ISCS從各系統(tǒng)讀取信息ISCS向各系統(tǒng)寫信息或命令協(xié)議測試環(huán)境如下圖所示：ISCS系統(tǒng)ISCS系統(tǒng)FEP便攜式PC機各子系統(tǒng)仿真器或實際設備圖STYLEREF1\s3SEQ圖\*ARABIC\s11協(xié)議測試環(huán)境示意圖冗余測試冗余測試用來檢查ISCS與接口系統(tǒng)間冗余機制是否滿足協(xié)議規(guī)定及用戶需求，冗余測試根據(jù)實際情況在工廠或工程現(xiàn)場進行，冗余測試應使用實際設備進行測試，不建議使用模擬器進行仿真測試，冗余測試至少涉及以下內容：正常情況下，ISCS與接口系統(tǒng)之間的冗余機制建立ISCS冗余設備故障時，ISCS與接口系統(tǒng)之間連續(xù)通訊及故障隔離測試。接口系統(tǒng)冗余設備故障時，ISCS與接口系統(tǒng)之間連續(xù)通訊及故障隔離測試點對點測試點對點測試用于檢查ISCS和接口系統(tǒng)數(shù)據(jù)庫之間點的相應關系，并檢查ISCS計算機和各系統(tǒng)通過以太網(wǎng)/串行接口傳輸?shù)乃袛?shù)據(jù)點對的性，測試中使用測試設備檢查從ISCS服務器到相關各系統(tǒng)的控制器/終端的數(shù)據(jù)點相應。本工程將進行100%的點對點測試，100%點對點測試可以大量減少現(xiàn)場測試/校正的時間，點對點測試將于ISCS/各系統(tǒng)的單機單系統(tǒng)工廠驗收完畢后進行。點對點測試建議采用如下環(huán)節(jié)：各系統(tǒng)人員模仿本系統(tǒng)狀態(tài)的變化ISCS人員檢查FEP是否接受到了對的值測試所有狀態(tài)ISCS人員模擬發(fā)出一個去各系統(tǒng)的控制命令各系統(tǒng)人員檢查各系統(tǒng)是否接受到了對的命令測試所有控制命令點對點測試環(huán)境如下圖所示：ISCS系統(tǒng)ISCS系統(tǒng)FEP便攜式PC機子系統(tǒng)系統(tǒng)實際設備便攜機圖STYLEREF1\s3SEQ圖\*ARABIC\s12點對點測試環(huán)境示意圖端對端測試端到端測試將使用測試設備保證ISCSHMI上顯示的點與現(xiàn)場各系統(tǒng)設備之間的信息點相應關系。本工程將在現(xiàn)場進行100%的端到端測試（每個設備類進行100%的端到端測試），端對端測試將于ISCS/各集成/互聯(lián)系統(tǒng)的單機現(xiàn)場驗收完畢后的聯(lián)調中進行，在端對端測試中ISCS承包商負責從綜合監(jiān)控系統(tǒng)到各接口系統(tǒng)的接口數(shù)據(jù)對的。端對端測試的目的是：檢查從ISCS的人機界面（HMI）到現(xiàn)場設備的正?？刂乒δ?；驗證ISCS對各接口各系統(tǒng)設備的正常監(jiān)視功能；端對端測試建議采用如下環(huán)節(jié)：各系統(tǒng)人員改變現(xiàn)場設備狀態(tài)ISCS人員檢查ISCSHMI接受和顯示的值是否對的測試100%信息點ISCS人員發(fā)送一個控制命令到各系統(tǒng)各系統(tǒng)人員檢查本系統(tǒng)是否對的執(zhí)行了命令并且反信給ISCS測試100%控制命令。端對端測試環(huán)境如下圖所示：ISCISCS系統(tǒng)HMIISCS服務器ISCS系統(tǒng)FEP子系統(tǒng)實際通訊設備就地設備圖STYLEREF1\s3SEQ圖\*ARABIC\s13端對端測試示意圖功能測試本工程將在現(xiàn)場進行功能測試，通過接口功能測試檢查ISCS系統(tǒng)和被接入系統(tǒng)接口部分的功能是否達成協(xié)議規(guī)定和用戶需求，功能測試應對具體接口規(guī)范中列出的功能接口進行逐個測試，保證在ISCS系統(tǒng)中的各系統(tǒng)功能的得到了正的確現(xiàn)。性能測試本工程將在現(xiàn)場進行性能測試，以驗證ISCS系統(tǒng)是否滿足DIS中規(guī)定的性能需求，測試將針對從各系統(tǒng)現(xiàn)場設備到ISCS的整個鏈路，性能測試的目的是保證數(shù)據(jù)在承諾的時間內從各系統(tǒng)傳送到ISCSHMI。下述測試環(huán)節(jié)僅為舉例說明，最終的具體測試環(huán)節(jié)將在接口測試規(guī)范（ITSP）中給出。在現(xiàn)場改變一個設備狀態(tài)，計時開始。協(xié)議分析儀監(jiān)測到接口端子的網(wǎng)絡數(shù)據(jù)，第一次計時停止。ISCSHMI上的相關設備圖標發(fā)生變化，第二次計時停止。在ISCSHMI上發(fā)送一個控制命令，計時開始。協(xié)議分析儀監(jiān)測到接口端子的網(wǎng)絡數(shù)據(jù)，第一次計時停止?，F(xiàn)場設備執(zhí)行控制命令，設備狀態(tài)改變，第二次計時停止性能測試環(huán)境如下圖所示：ISCS系統(tǒng)ISCS系統(tǒng)HMIISCS服務器ISCS系統(tǒng)FEP子系統(tǒng)實際通訊設備就地設備圖STYLEREF1\s3SEQ圖\*ARABIC\s14性能測試環(huán)境示意圖檢查流程北京地鐵十四號線ISCS接口測試將按照下圖顯示的流程進行：圖STYLEREF1\s3SEQ圖\*ARABIC\s15檢查流程示意圖與公共管理部門的協(xié)調也許需要與公安部門以及消防部門進行協(xié)調。我們盼望這種協(xié)調將在業(yè)主的權限內進行。我們建議每次會議都有業(yè)主的代表到場，并且我們還建議管理部門所需的所有信息都應當傳送給北京和利時公司。文獻控制規(guī)則與流程在項目文獻控制程序中規(guī)定了與文獻控制有關的規(guī)則。當項目管理計劃與項目文獻控制流程之間發(fā)生沖突時，將按照下面的優(yōu)先順序執(zhí)行：項目管理計劃；項目文獻控制流程。文獻發(fā)放技術文獻發(fā)放一般而言，技術文獻