仓储运输及安装调试方案样本.doc

资料内容仅供您学习参考，如有不当之处，请联系改正或者删除。

项目组织施工验收方案 、 设备安装、
调试方案

项目进度控制计划
项目管理计划包括以下15个方面:
Ø 项目计划和商业/合同管理;
Ø 工作分配: 为工作包或项目副经理定义工作对象/范围;
Ø 预算分配和预算管理;
Ø 要求和配置管理;
Ø 经过报告、 会议、 复查进行进度监控( 包括协调并向用户汇报) ;
Ø 协调和沟通;
Ø 接口管理;
Ø 与政府部门/管理当局的协调;
Ø 文件控制;
Ø 采购和分包商管理;
Ø 设备交货后的管理;
Ø 工地组织和结构;
Ø 综合后勤支持;
Ø 质量管理;
Ø 风险管理。
下面将详细描述项目管理的15个方面:
项目计划
北京和利时公司将制定总体项目计划, 具体由项目计划与合同管理组完成。下列文件提供了详细的项目计划:
Ø 设计和制造计划;
Ø 软件开发计划;
Ø 安装测试计划。
工作分配
目的是为不同的项目小组分配工作。根据工作分工, 北京和利时公司制定项目的WBS( 工作分解结构) 文件, WBS的每项工作都被分配给OBS的至少一个小组。
每位项目副经理对自己小组的工作结果负责, 并向项目经理/主管汇报工作。因此每位项目副经理都必须对分配给自己小组成员的工作以及她/她的工作范围的任务负责。
关于人力资源, 每个小组必须明确自己的需要以便能够独立处理自己工作范围内的工作。如果要增加资源, 项目副经理必须向项目经理/主管请示。
本文的”附件一”给出了北京地铁十四号线基本的WBS。
预算分配和管理
项目经理分配给每一位项目副经理一份预算以便其完成自己的工作。成本管理员定期跟踪项目副经理的预算以更新她们的预算状况。
每位项目副经理都必须考虑在合适的技术和组织选择方面分配其预算。
每三个月要求每位项目副经理向成本管理员提供一份包含如下内容的预测报告:
Ø 完成工作所需的资源;
Ø 未付费用/采购费。
然后, 成本管理员会更新预测的工作预算。在超支的情况下, 项目副经理必须向项目管理小组提供一份恢复计划。
为了满足用户的进度的要求, 进度要求的满足将优先成本方面的考虑, 即将不计较成本, 首先满足进度要求。
需求与配置管理
需求管理
需求管理是开发综合监控系统软件, 完成综合监控系统工程的一个主要的组成部分。
下面几节的目的在于提供已经定义好的特别是软件功能需求方面的一般规则, 并描述组织结构情况以便具备一个有效的需求管理系统。
一般规则
DOORS套装软件是一套公认的软件包, 它用于管理复杂系统的需求而且已经被北京和利时公司采用。
北京和利时公司已经开发了一个应用层并将其与DOORS集成在一起, 并在深圳地铁2号线和深圳地铁4号线成功应用此需求管理软件。为了用一种精确、 有效的方法跟踪本合同的要求, 北京和利时公司已经决定在整个十四号线项目期间使用DOORS软件包作为需求管理工具。
一般过程
一般过程如下所述:
Ø 将用户所有的技术要求输入到DOORS;
Ø 将系统需求规范( SRS) 的系统要求输入到DOORS模块中去;
Ø 将详细的接口规范( DIS) 的要求输入到DOORS模块中去;
Ø 将上述SRS和DIS中包含的需求分配给DOORS模块中被称作系统设计规范( SDS) 的工作分解项, 该项列在工作分解结构中。这些配置项目, 既包含硬件配置项( HWCI) 又包含软件配置项目( CSCI) ;
Ø 根据系统需求以及SRS和DIS中规定的要求, 将DOORS模块中的CSCI和HWCI撰写为软件需求规范( SWRS) 和硬件需求规范( HWRS) ;
Ø 将CSCI和HWCI的要求分配给工作分解结构DOORS模块中被称作软件设计规范( SWDS) 和硬件设计规范( HWDS) 的配置项目;
Ø 给对应于上述细分结构的不同层次的测试定义集成、 验证和确认( IVV) 模块;
Ø 对于变化跟踪来说, 无论是出于什么原因 ( 用户、 设计约束、 技术最优化的建议) 引起的所有的技术变化都由工程变更控制系统管理。
需求管理组织
由于需求管理系统专门用于技术需求, 因此它由系统工程经理和系统与集成小组负责。
DOORS工具的管理由系统配置工程师执行。
系统配置管理
配置管理计划中规定了整个项目期间都要遵循的与系统配置管理有关的规则。
当项目管理计划和配置管理计划之间发生冲突时, 将按照下面的优先次序执行:
Ø 项目管理计划;
Ø 配置管理计划。
为了能够根据清晰设计而开发系统, 及为了拥有一套一致的文件和DOORS模块, 将定期更正系统基准。在整个项目期间, 该过程都会进行。
配置控制委员会( CCB) 将负责在整个项目周期中定义各种基准。
系统配置工程师将负责跟踪并监督将投入使用的基准系统。
将遵循的一般规则如下所示:
Ø 在给定的参考系中, 系统基准与一套基准的DOORS模块对应;
Ø 对应于给定基准的文件将储存在DOORS模块中;
Ø 将有两类基准:
¨ 正式基准: 它们对应一套模块包括基准和正式提交给用户的基准;
¨ 非正式基准: 它们对应一套于DOORS模块的基准, 但未包含在正式提交给用户的基准。
Ø 无论是什么原因要求变更文件, 都必须向负责确认并决定何时执行变更的CCB提交一份变更建议: 在CCB做出正式决定之前, 任何人都不能擅自变更作为基准的模块;
Ø 当CCB做出执行变更的决定时, 变更及其相关影响将输入到DOORS中去。进行变更后, 所有修改过的文件都必须进行基准变更, 而且系统基准也必须进行相应地变动;
Ø 正式文件基准按照文件的修订版进行命名;
Ø 非正式文件基准按照正式最新的修订版参考号并后加一个字母命名;
Ø 正式系统基准的名称由字母”S”后接1~99的数字构成;
Ø 非正式系统基准由字母”S”后接1~99的数字以及一个小写字母构成;
Ø 为了检查是否正确执行了变更情况, 必须使用一个跟踪系统。这种监督工作由系统配置工程师负责;
Ø 在项目的任何阶段, 任何活动都必须按照当前批准的系统基准进行。
软件配置管理
软件配置管理计划中规定了软件配置管理的规则和程序。
在配置管理计划和软件配置管理计划发生冲突时, 将按照下面的优先顺序执行:
Ø 配置管理计划;
Ø 软件配置管理计划。
复查、 汇报、 会议及审核
除了设计联络会, 将执行下面的复查、 汇报、 会议和审核:
内部月进度审查会
项目经理每月经过月项目审查会向项目管理部主管汇报工作。
每位项目副经理都必须在审查会之前至少一周向项目经理提供与其工作有关的信息以便进行汇总。成本管理员负责将各种报告汇总到审查会报告中去, 以便项目经理在审查会前进行分析。成本管理员负责组织这些会议并通知相关的与会人员。
内部季度预算审查会
项目经理经过季度预算审查会每年向项目管理部主管和成本管理员汇报4次工作。
每位项目副经理在季度预算审查会前至少3周向项目经理提供与其工作有关的预算信息用于信息汇总。成本管理员负责将各种数据汇总到项目季度预算审查会中去, 以便项目经理在季度预算审查会前进行分析。
成本管理员负责组织这些会议并通知相关与会人员。
内部进度会
北京和利时公司每周将各举行一次公司内部进度会。所有的项目副经理都必须参加。对于某些会议来说, 可能会邀请额外的项目小组成员参加。这些会议将在每周一下午4点举行。如遇公共假期, 则会议自动顺延至第二天的同一时间举行。如遇特殊情况, 会议能够延期举行。
项目月进度会
北京和利时公司每月举行月进度会, 该会议是北京和利时公司基于项目管理层面, 项目副经理也参加会议。对于某些会议, 可能会邀请额外的项目小组成员参加。这些会议由项目经理组织并主持。
对于相关的每月进度报告:
Ø 将在每月5号提交;
Ø 每位项目副经理都必须填写部分与其工作范围相关的报告;
Ø 秘书负责组织收集各种报告并将其编入每月进度报告。必须在每月5号前至少两天将报告草案提交给项目经理审阅。
阶段性审查
在项目施工期间, 在每个重要阶段结束时都要进行内部审查, 内容包括:
Ø 系统设计审查( SDR) : 目的是审查详细接口规范( DIS) 、 系统需求规范( SRS) 、 系统设计规范( SDS, 包括SWDS和HWDS) 以及接口需求规范( IRS) ;
Ø 部件设计复查( CDR) : 目的是检查各子系统和系统组成部分的设计文件是否适合生产;
Ø 系统测试准备就绪复查( STRR) : 目的是检查与系统测试相关的文件是否允许在工厂进行系统测试以及在现场以一种控制方式进行系统测试。
配置审核
配置审核能够用来验证系统和配置项目与其基准是否相符。
质量系统管理审查和预防性措施
北京和利时公司将审查本项目中执行的质量系统的适宜性和有效性。由计划经理准备预防性措施分析报告以分析内部审核、 用户审核和日常操作中发现的非一致性问题。然后将在每年至少举行一次的质量系统的管理复查会上审阅预防性措施分析报告。质量系统的管理复查会将由项目管理部主管主持, 与会人员包括质量工程师、 系统工程经理以及由会议主席确定的其它特别与会人员。流程包括:
Ø 配置管理流程;
Ø 质量系统改进和控制流程;
Ø 质量保证流程;
Ø 预防性措施流程。
协调与沟通
项目信息的沟通在综合监控系统项目内显得非常重要, 不但是在团队内部各职能小组之间需要进行及时的沟通联络, 同时该项目的一个突出特点已经决定了该项目需要大量的接口协调工作, 即北京和利时公司需要同若干个项目组织之间建立通畅的信息沟通渠道和高效信息沟通流程, 这对于保证综合监控系统项目的顺利进行和高质量的完成都具有重要的意义。该项目管理将重点关注项目的沟通管理, 将配合业主和监理建立一套基于该项目各相关组织之间的沟通计划。
北京地铁十四号线综合监控系统项目将需要与以下各方进行强有力的协调与频繁联络:
Ø 北京地铁公司( 包含ISCS业主及其它专业业主) ;
Ø 工程监理;
Ø 设计院;
Ø 土建承包商;
Ø 安装承包商;
Ø 其它的接口系统/设备供应商。
为了有效实现这种协调, 在设计和开发阶段, 工作人员将在北京工作, 在现场安装/接口/测试阶段以及保修期内其工作人员将在北京工作。
协调活动包括两类:
Ø 接口设计;
Ø 现场协调。
接口设计计划
对于顺利完成像北京地铁十四号线综合监控系统这样的工程, 接口管理是一个非常重要的问题。对于项目开发来说, 接口管理活动是主要的信息来源之一, 而且在整个工程期间它都需要与其它各方进行强有力的协调。
本接口管理计划( IMP) 定义了用来开发ISCS和接口系统之间详细接口要求的管理过程。本计划的目的是为无缝集成提供方便, 使其符合ISCS用户需求以及接口设备规范。
另外, IMP将提出北京和利时公司与接口承包商用来定义两个系统间接口的详细要求的过程。接口管理将在接口文件中提出下面的属性:
Ø 电气、 机械、 软件协议以及功能数据接口;
Ø 检查、 测试和试运行。
文件也将定义进行资源管理、 文件变动控制、 北京和利时公司和接口承包商之间沟通以及冲突解决所需的过程。
接口设计
详细的接口设计参见《B2-2 综合监控专用技术册( 下) 》中的论述。
沟通与交流
接口会议
接口会议的工作范围如下所示:
Ø 了解各方的设计要求, 开发并协商经过设计和接口要求以满足北京地铁合同中所规定的要求;
Ø 确定影响接口设计的关键性能参数和问题;
Ø 确定设计阶段、 安装阶段以及试运行阶段的测试要求细节;
Ø 按照每个合同中的总规划协商经过设计和测试程序;
Ø 协商提交给北京地铁的接口文件。
接口会议的时间及地点安排将由接口双方协商。我们建议在北京举行接口会议。
承包商之间的信息交流
承包商之间经过图纸和说明性文件这两种方法进行信息交流。能够在接口会议期间或者经过正式公文交流信息。
经过图纸交流的信息包括结构图、 机械详图、 电器详图、 接口电路图、 接线图等等。说明性文件用来描述程序、 系统特点、 电器特点、 测试要求以及会议记录, 包括行动表。
双方利用电子邮件、 传真或电话经常保持沟通以明确设计和所有后勤安排的细节。达成的协议将在接口会议后形成会议纪要或正式的可发布文件。
需要业主的支持
双方在接口会议期间经过正式文件解决问题。当确认问题需要北京地铁介入时, 双方或者在接口会议的纪要中或者经过书面通知业主。
当无法就关键问题达成协议或者对各方合同中的特殊需求或接口规范要求的解释持不同意见时, 将马上以书面形式向业主发出仲裁和确认请求。业主出席会议将加速问题的解决。
接口文件
将为每位接口承包商准备下列文件:
详细的接口规范( DIS)
文件的目的
Ø 目的是规定并描述与ISCS和接口系统间接口相关的所有信息;
Ø 由于在系统设计阶段不可能获取所有的信息, 本文件将在项目进行期间不断进行修正。
文件管理和提交
Ø DIS是一种ISCS文件, 由北京和利时公司制作和管理。在向业主发布前, 将由接口承包商复查本文件。我们建议与其它的接口承包商正式签署DIS文件;
Ø 接口承包商也能够将DIS用于自己的接口文件。我们建议使用没有改动过的文件, 而且建议加上一个封皮, 使接口承包商文件在参考上与接口承包商规范保持一致;
Ø 两个封面的重叠将表明文件修订版是如何与双方的合同保持同步的。
典型的文件格式见Error! Reference source not found.
表 01典型文件格式
组成部分
内容
1. 目的
本部分应叙述有关的接口及两个合同参考
2. 参考文件
本部分将涉及ISCS规范的相关部分和附录。本部分也包括参考标准或其它的应用文献。
3. 术语表
任何使用过的首字母缩写词的含义。
解释相关或必要的词汇或技术用语。
4. 接口规范
4.1 接口图
接口图中指出了工作范围和责任范围。
4.2 物理接口
4.2.1 特性和位置
一张表表明每个接口的特性和准确位置。位置可能是车站、 车辆段、 OCC( 控制中心) 或一座辅助建筑物内的一个房间。
4.2.2 电气描述
本部分包括一张原理图, 图中标明了成分、 电缆以及接线安排的电压、 电流或阻抗规格以及电源规格。
4.2.3 机械描述
本部分包括:
-端子柜编组原则;
-机柜尺寸和安装;
-接线柱、 插座和接线端子。
4.3 功能接口
本部分的目的是提供两方面的要求了解。
接口设备及其监控数据和功能将按照ISCS和接口商的最初合同要求列出来。
4.4 协议
本部分将提供用于接口的详细软件协议。
4.5 命名惯例
本部分将说明用来识别ISCS和接口系统中的每种信息的命名惯例。
命名惯例将用来识别ISCS工作站中的信息和为设备、 电缆以及接线端子加标签。
4.6 设计约束条件
本部分将列出所有的设计约束条件, 例如, 特殊响应时间、 通信软件版本, 等等。
4.7 EMC( 电磁兼容性)
如果存在, 则本部分将说明所有的电磁兼容性的约束或问题。
5. 执行和安装
本部分将包括所有的执行和安装事件( 如果存在) 。
5.1 限制条件
本部分的目的是尽早发现实施或安装方面存在的限制: 空间规定、 接入日期和特殊工具, 等等。
如果限制条件影响接口实施和安装程序, 则该限制条件将包含在实施和安装程序中。
如果需要特别关注, 则一个限制将被看成是一个特殊的接口问题。
5.2 程序
本部分将提供一个接口实施和安装程序, 该程序至少应该包含两位承包商所提供的信息和她们根据各自的目标开工和完工日期所采取的行动。
6. 质量保证

6.1 接口要求参考
本部分是一个基本的相互参照表, 它为DIS中所规定的每条要求提供了它们相应最初的规范要求。
6.2 验证和确认
本部分是一个基本的表格, 它为DIS中所规定的每条要求提供了验证方法。
附录和图纸
详细的数据接口附录
对于每个接口位置来说, 详细的数据接口表包括:
信息标识符( 设备和数据) ;
信息描述( 设备状态) ;
对应值;
点或信息位置( 例如在一张表中列出) 及地址。
电缆、 接线端子和图纸
本附录包括所有的电缆路由选择、 电缆终端、 配置、 机柜安排、 结构规定以及空间规定和电路图。
系统启动参数

详细的接口测试计划( DITP)
文件的目的
本文件的目的是定义并描述如何在设计阶段实现接口测试, 以达到如下目标:
Ø 首先, 确认计划的测试是否必要和充分;
Ø 其次, 组织单独测试, 然后与接口承包商一起组织联合测试。
文件管理和提交
Ø DITP是一种ISCS文件, 由北京和利时公司制作和管理;
Ø 在提交给业主之前, 将由接口承包商审查本文件;
Ø 我们建议接口承包商也能够将DITP用于自己的接口文件。我们建议接口承包商使用没有改动过的文件, 而且建议加上一个封皮带有与接口承包商规范保持一致;
Ø 两个封面的重叠将表明文件的修订版是如何与双方的合同保持同步的。
文件内容见Error! Reference source not found.
表 02文件内容
组成部分
内容
1. 目的
本部分应叙述有关的接口及两个合同参考。
2. 参考文件
本部分将参考ISCS规范的相关部分和附录。本部分也包括参考标准或其它的应用文献。
3. 术语表
任何使用过的首字母缩写词的含义。
解释相关或必要的词汇或技术用语。
4. 测试方法
本部分将描述在工厂测试阶段和现场测试阶段如何测试接口, 并强调每个阶段接口测试的重叠部分。
5. 接口测试规范
本部分将为工厂和现场测试总结出建议测试程序。
5.1 测试标识符
对于每一种测试, 都将分配一个测试标识符。
5.1.1 测试的目的
简要描述测试的目的。
5.1.2 需求参考
本部分将参考本程序所验证的接口要求。
5.1.3 测试配置
本部分描述了完成测试所必须的硬件和软件配置。
5.1.4 测试设备
本部分列出了所有必须的测试设备及她们个别的用途。
5.1.5 测试程序
本部分包括用于相关的测试表的典型格式。
6.测试的逻辑顺序
本部分描述了完成测试的逻辑顺序。
7.质量保证
7.1接口要求参考
本部分是一个基本的相互参照表, 它为DIS中的每条要求提供了它们相应最初的规范要求。
附录&图纸

接口测试规范程序( ITSP)
文件目的
Ø 每个ITSP是一种测试程序, 它描述了工厂接口测试、 现场接口测试、 现场端到端测试期间完成的每项测试;
Ø 在系统验收期间, 测试程序将被ISCS工程师和接口承包商的工程师用作验收检验程序。
文件管理和提交
Ø ITSP是一个ISCS和接口承包商的共同文件。它将由ISCS和接口承包商共同制作、 复查并向其各自的工程师发布;
Ø 本文件将被两位承包商同时参照, 以管理它们各自的文件参考系统。
接口测试程序的内容
Ø 测试的所有细节、 先决条件、 测试行动以及预期的测试效果都将编入本文件。测试表将在测试期间使用和填写。因此, 相关的测试表将由北京和利时公司和其它的承包商签署并编入测试报告。
接口文件的版本控制
文件版本控制将在每位承包商制定好质量程序之后进行。该文本文件包括一张变动控制和签名页以识别以前版本的变动情况。文本中可用下划线来识别复查过程中的具体变动。在新版本中添加了工具条以表明变动情况。
接口变更管理
接口设计变更过程
在项目周期中, 可能有变更接口要求以改进设计、 改正错误并最小化风险。
接口设计变更过程确保:
Ø 所有建议的用于接口要求的硬件、 软件或文件变更都必须汇报、 记录、 跟踪并解决;
Ø 用一种清晰、 一致的方式提出变更说明书;
Ø 全面评估变更建议并接受正确的处理方案;
Ø 能够看到所有变更状态;
Ø 而且所有的传达和传达途径都进行了很好的定义。
将由ISCS和接口承包商共同制定详细接口规范。在批准DIS时, 将对接口设计( 设计冻结) 进行基准化。在最初提交后, 进行的任何变更都将按接口变更过程执行。
接口需求变更报告
接口需求变更报告是为重要接口问题或异常现象而编制的文件。问题可能会与接口需求的任何一方有关。接口变更报告可能会使用一种标准形式、 用一种简洁的方式提出主题: 提供问题的描述并证明正确的变更建议。
接口需求变更报告将提出所有的相关事实以指出变更的重要性, 例如所要求变更的细节、 如果不变更的风险、 建议的应用以及建议的优先水平等。
接口需求变更报告应该表明设计变更建议是否与规范要求和安全要求相符。接口需求变更报告也应该识别正确设计变更是否偏离了这些要求。承包商将决定是否需要召开会议。
变更建议的审查
接口需求变更报告将由业主和两位承包商共商复查以确保它描述了实际的问题而且附上到了所有相关的数据。业主和承包商之间的正式、 非正式文件将阐明或完成对所提出数据的理解。
如果有必要召开会议来讨论变更建议, 那么在可能的情况下将在会议上把众多的变更建议进行讨论。如果复查过程做出了变更结论, 则将要求最初的承包商返工。
业主和承包商在复查过程中要求的内部安全和系统设计复查将按照它们各自的管理程序进行。
变更将经过与会的授权代表复查并记录于会议纪要中。
接口测试
为保证ISCS与各系统间接口的正确性, 北京和利时公司采用不限于以下内容的测试方法检验系统间接口是否满足合同需求及相关技术规范。
技术要求
检验方法
物理接口
负责连接ISCS与各系统
目视检查, 冗余测试, 通讯测试
功能接口
ISCS与各系统之间实现的具体功能
点对点测试, 端对端测试, 功能测试, 性能测试
协议
ISCS与各系统之间通讯采用的具体协议
协议测试
数据接口
各系统向ISCS提供的信息点
点对点测试, 端对端测试
检验及确认
目视检查
为确保ISCS与各系统承包商提供的接口满足用户需求, 能够采用目视检查或尺寸测量的方法进行检查, 不需要专用的仪器设备, 对各承包商提供的接口应进行100%的目视检查以确保接口安装的正确性。
目视检查测试的主要对象是所有物理接口的连接电缆及接口设备( 包括: 电缆安装、 端子排布置, 转换器的安装位置等) , 目视检查将参照DIS中规定的ISCS与各系统接口划分及工艺图纸中来执行, 目视检查不包括电缆的连接电气测试, 该测试应该在安装阶段完成。
目视检查遵循以下步骤:
Ø ISCS人员核对所有电缆是否已经在接口点处安装就绪, 而且是否选择了最恰当的敷设路线。
Ø ISCS人员核对所有电缆连接的正确性。
通讯测试
通讯测试确保各系统设备不同模块之间能正常通讯, 测试将在现场进行。通讯测试的目的是确保所有物理接口的两端经过电气连接测试, 确保ISCS 和各系统两端能够建立通讯连接。
通讯测试包括以下步骤:
Ø ISCS人员使用万用表作为测试工具, 测试接口双方的电气连接。
Ø ISCS人员将便携机连接到ISCS FEP ( 该便携机能够监视局域网数据和连接状态) 。
Ø ISCS人员经过便携机检查连接状态。
协议测试
通讯协议的测试目的是检验接口软件功能, 确保ISCS和各系统承包商双方开发的协议及通讯机制达到设计规范; 同时检验软件接口部分是否遵守协议文件, 并澄清在协议文本中没有描述清楚的内容。协议测试应至少包含对所有命令和数据的格式、 收发的机制和例外处理等的测试。协议的测试应经过实际设备进行, 除非北京地铁允许, 一般不建议采用模拟器进行协议测试。
在详细接口规范中描述的接口协议被认可的情况下, ISCS和各系统应该履行协议测试, 确保承包商双方正确实现接口协议, 并澄清协议文件中未作规定的问题。
协议测试将测试以下功能:
Ø 系统初始化
Ø 消息格式的正确性
Ø ISCS从各系统读取信息
Ø ISCS向各系统写信息或命令
协议测试环境如下图所示:
ISCS系统FEP
便携式PC机
各子系统仿真器或实际设备

图 01 协议测试环境示意图
冗余测试
冗余测试用来检查ISCS与接口系统间冗余机制是否满足合同要求及用户需求, 冗余测试根据实际情况在工厂或工程现场进行, 冗余测试应使用实际设备进行测试, 不建议使用模拟器进行仿真测试, 冗余测试至少包括以下内容:
Ø 正常情况下, ISCS与接口系统之间的冗余机制建立
Ø ISCS冗余设备故障时, ISCS与接口系统之间连续通讯及故障隔离测试。
Ø 接口系统冗余设备故障时, ISCS与接口系统之间连续通讯及故障隔离测试
点对点测试
点对点测试用于检查ISCS和接口系统数据库之间点的对应关系, 并检查ISCS计算机和各系统经过以太网/串行接口传输的所有数据点正确性, 测试中使用测试设备检验从ISCS服务器到相关各系统的控制器/终端的数据点对应。本工程将进行100%的点对点测试, 100%点对点测试能够大量减少现场测试/校正的时间, 点对点测试将于ISCS/各系统的单机单系统工厂验收完成后进行。
点对点测试建议采用如下步骤:
Ø 各系统人员模仿本系统状态的变化
Ø ISCS人员检查FEP是否接收到了正确值
Ø 测试所有状态
Ø ISCS人员模拟发出一个去各系统的控制命令
Ø 各系统人员检查各系统是否接收到了正确命令
Ø 测试所有控制命令
点对点测试环境如下图所示:
ISCS系统 FEP
便携式PC机
子系统系统实际设备
便携机

图 02 点对点测试环境示意图
端对端测试
端到端测试将使用测试设备确保ISCS HMI上显示的点与现场各系统设备之间的信息点对应关系。本工程将在现场进行100%的端到端测试( 每个设备类进行100%的端到端测试) , 端对端测试将于ISCS/各集成/互联系统的单机现场验收完成后的联调中进行, 在端对端测试中ISCS承包商负责从综合监控系统到各接口系统的接口数据正确。
端对端测试的目的是:
Ø 检查从ISCS的人机界面( HMI) 到现场设备的正常控制功能;
Ø 验证ISCS对各接口各系统设备的正常监视功能;
端对端测试建议采用如下步骤:
Ø 各系统人员改变现场设备状态
Ø ISCS人员检查ISCS HMI接收和显示的值是否正确
Ø 测试100%信息点
Ø ISCS人员发送一个控制命令到各系统
Ø 各系统人员检查本系统是否正确执行了命令而且反信给ISCS
Ø 测试100%控制命令。
端对端测试环境如下图所示:
ISCS系统HMI
ISCS 服务器
ISCS系统 FEP
子系统实际通讯设备
就地设备

图 03 端对端测试示意图
功能测试
本工程将在现场进行功能测试, 经过接口功能测试检验ISCS系统和被接入系统接口部分的功能是否达到合同要求和用户需求, 功能测试应对详细接口规范中列出的功能接口进行逐一测试, 确保在ISCS系统中的各系统功能的得到了正确实现。
性能测试
本工程将在现场进行性能测试, 以验证ISCS系统是否满足DIS中规定的性能需求, 测试将针对从各系统现场设备到ISCS的整个链路, 性能测试的目的是保证数据在承诺的时间内从各系统传送到ISCS HMI。
下述测试步骤仅为举例说明, 最终的详细测试步骤将在接口测试规范( ITSP) 中给出。
Ø 在现场改变一个设备状态, 计时开始。
Ø 协议分析仪监测到接口端子的网络数据, 第一次计时停止。
Ø ISCS HMI上的相关设备图标发生变化, 第二次计时停止。
Ø 在ISCS HMI上发送一个控制命令, 计时开始。
Ø 协议分析仪监测到接口端子的网络数据, 第一次计时停止。
Ø 现场设备执行控制命令, 设备状态改变, 第二次计时停止
性能测试环境如下图所示:
ISCS系统HMI
ISCS 服务器
ISCS系统 FEP
子系统实际通讯设备
就地设备

图 04 性能测试环境示意图
检验流程
北京地铁十四号线ISCS接口测试将按照下图显示的流程进行:

图 05 检验流程示意图
与公共管理部门的协调
可能需要与公安部门以及消防部门进行协调。
我们期望这种协调将在业主的权限内进行。我们建议每次会议都有业主的代表到场, 而且我们还建议管理部门所需的所有信息都应该传送给北京和利时公司。
文件控制
规则与流程
在项目文件控制程序中规定了与文件控制有关的规则。当项目管理计划与项目文件控制流程之间发生冲突时, 将按照下面的优先顺序执行:
Ø 项目管理计划;
Ø 项目文件控制流程。
文件发放
技术文件发放
一般而言, 技术文件不发放给项目参与人, 所有的资料都按文件管理的规定存放在公司的冗余文件服务器中。人们能够经过资料室查阅技术文件, 而且能够随时进行查阅。
可是, 一些重要文件在每次更新后必须由秘书发放给大家。这些文件是:
Ø 管理计划的最新版本;
Ø 质量计划;
Ø 健康和安全计划。
就健康和安全计划的特殊情况而言, 每位参与本项目的人员都必须经过签字确认收到了健康和安全计划。
本文件的发放由秘书组织。秘书必须在与安全计划有关的文件夹中登记经签字的确认收据。
秘书也必须把某些文件以及它们相关的应用程序最新版本的打印文件进行存放。任何参加该项目的人员都必须很容易地访问到该文件夹以便进行咨询。这些文件是:
Ø 当前的管理计划以及相关的参考程序;
Ø 质量计划以及相关的参考程序;
Ø 健康和安全计划以及相关的参考程序;
Ø 需求管理计划以及相关的参考程序;
Ø 项目文件控制程序以及相关的参考程序;
Ø 软件配置管理计划以及相关的参考程序。
每一位参加本项目的工作人员在完成其任务和职责的过程中都必须查阅该文件夹。每位项目副经理负责确保自己的小组成员实施了上述文件中所描述的规则和程序。
秘书将负责本文件夹的任何变动( 添加文件、 更新文件等等) 。
其它文件发放
秘书负责按照项目文件控制程序发放其它文件( 传真、 信件、 会议记录等等) 。
采购和分包合同管理
采购
本项目的采购活动北京和利时公司将按照相关的规则与程序办理。
北京和利时公司的采购经理负责本项目责任范围内的采购工作。
分包合同管理
本项目的采购活动北京和利时公司将按照相关的规则与程序办理。
北京和利时公司采购经理负责本项目责任范围内的采购工作和分包合同的管理工作。
设备交货后的管理
设备交货后的管理由北京和利时公司的现场小组负责配合业主完成。由采购经理协助其完成这项工作。
现场组织与资源
北京现场的组织及资源包括:
北京和利时公司向业主仓库/库房运送和交付货物以便进行储存;
北京和利时公司负责设备向现场的转移;
北京和利时公司负责设备在机架和控制台上的物理安装督导。
综合后备支持
综合后备支持包括整个系统周期内进行的活动以提供预期的效果可能性。
包括:
Ø 备品备件( 更加详细的内容能够参看《B1　综合监控系统通用技术册》第5章节) ;
Ø 专用工具、 测试仪器( 更加详细的内容能够参看《B1　综合监控系统通用技术册》第5章节) ;
Ø 技术文件及图纸: 设计、 安装、 操作和维修( 更加详细的内容能够参看《B1　综合监控系统通用技术册》第16章节) ;
Ø 技术培训( 更加详细的内容能够参看《B1　综合监控系统通用技术册》第15章节) 。
质量管理
质量计划中定义了整个项目期间要遵守的与质量有关的规则。
当现在的计划与质量计划发生冲突时, 按照下面的优先顺序执行:
Ø 项目管理计划;
Ø 质量计划。
风险管理
风险管理是项目管理中必不可少的一部分。下面几节的目的在于解释将用于本项目的风险管理规则。
风险管理规则
风险管理规则是基于质量程序文件中的建议而制定的。
风险管理活动
将完成的活动如下图所示:
Ø 风险识别;
Ø 风险评估;
Ø 检验和确认;
Ø 行动计划;
Ø 行动计划进度管理。