地铁系统保证计划模板

XX地铁X号线一期工程项目乘客信息系统设备项目系统保证计划XX科技发展有限公司文件编号：O终定版系统保证工程师系统保证经理项目经理2009.04.14A4提交第四版，供业主审核系统保证工程师系统保证经理项目经理2009.03.31A3提交第三版，供业主审核系统保证工程师系统保证经理项目经理2009.02.18A2提交第二版，供业主审核系统保证工程师系统保证经理项目经理2009.01.17A1提交初稿，以供业主审核系统保证工程师系统保证经理项目经理2008.9.28版本号内容编制审核批准日期承包商：XX科技发展有限公司 合约编号：更 改 履 历版本号日 期内 容A12008-09-28提交初稿，供业主审核A22009-01-17提交第二版，供业主审核A32009-02-18提交第三版，供业主审核A42009-03-31提交第四版，供业主审核O2009-04-14终定版目 录1概述51.1目的51.2范围51.3系统保证目标71.4故障的定义82参考文件和术语92.1定义及缩写92.2参考文件113XX地铁X号线一期工程乘客信息系统描述114RAMS工程管理组织及描述134.1组织架构134.2架构与功能的关系144.3沟通144.4角色及职责155系统安全分析及方法235.1系统安全235.1.1隐患分析235.1.2隐患分析程序245.1.3隐患结束需要考虑的内容275.1.4隐患的减轻措施275.1.5安全原则及规范要求的符合性评估及安全验证295.1.6安全分析报告305.1.7系统安全报告305.1.8风险等级评估305.1.9隐患的监控305.2系统RAM分析及方法315.2.1基本RAM计算方法325.2.2RAM分析335.2.3RAM证明375.2.3.1RAM证明计划375.2.3.2RAM证明报告386对分包商的监管396.1推荐的分包商396.2对分包商的系统保证管理396.3系统保证计划结束447故障报告与纠正措施系统447.1FRACAS系统的建立457.2FRACAS的运行过程及要求467.3FRACAS系统的运行要求488内部审核计划488.1内部审核的职责和方法488.2内部审核流程498.3内部审核遵循的原则508.4内部系统保证审核方案的内容508.5内部审核的组织安排508.6系统保证审核频率表519系统保证任务及提交文件时间表51附件1 风险矩阵53附件2 隐患登记册样式54附件3 安全原则及规范要求的符合性评估样式55附件4 系统安全报告结构及目录56附件5 FMECA样式57附件6 主要隐患清单58附件7 系统保证横道图59附件8 接口文件601 概述1.1 目的系统保证计划的目的是说明如何计划、管理及监控整体系统安全性、可靠性、可用性及可维护性（RAMS）要求；确保能有效地在设计、开发、生产、测试和初步运营阶段中落实相关设计目标。本系统保证计划概述了XX实施“系统保证”的方法，概述了PIS系统在设计、开发、生产、测试和试运营阶段的“系统安全及可靠性”的一般要求和所完成的具体任务，以确保在项目执行周期内的各个工程阶段中符合系统保证的各项要求，提交系统各个工程阶段所要求的系统保证计划任务和相应的文件，保证PIS系统的可靠性、可用性、可维护性和安全性（RAMS）方面满足规范、标准和买方的RAMS要求。1.2 范围XX地铁X号线一期工程乘客信息系统设备项目包括：XX地铁X号线一期工程线路、17个车站、1个控制中心、1个车辆段的乘客信息系统设备及各种安装材料供货及服务，并预留换乘车站和延伸线在技术上和物理上的扩容条件，以及与应急指挥中心、公安通信系统、大屏幕显示系统等的接口条件。乘客信息系统结构图如下图所示。PIS系统结构图XX地铁X号线PIS系统分为编播中心子系统、车站（含车辆段）显示子系统、车载显示及监视子系统。编播中心子系统是整个PIS系统的控制中心，负责乘客信息（包括紧急信息）的制作、接收和发布，以及通过传输网络将信息下发到车站或车载设备；集中定义和管理全系统各类型和级别的用户的操作权限，全面监视系统运营、监控系统设备的状态。主要设备包括：中心交换机、二级交换机、主备中心数据服务器、中心磁盘阵列存储设备、视频输入服务器、接口服务器、无线服务器、无线控制器、发布管理工作站、播出监看工作站、媒体编辑工作站、广告管理工作站、系统管理工作站、无线管理工作站、便携式数字高清DV摄像机、数字编辑录像机、数字编辑放像机、数字非线性编辑系统、录像机、DVD机、有线电视解调器、扫描仪、数字图像传输控制设备、车载视频解码设备、视频编码器、嵌入式数字硬盘录像机、LCD屏、监视器、车载视频控制键盘等。车站显示子系统通过星形光纤通信主干网连接至编播中心。车站服务器和LCD控制器接收来自编播中心的数字多媒体节目（包括乘客服务信息、娱乐、广告节目等）、节目调度表、实时营运信息等，通过LCD显示屏，按用户要求的时间、位置和播出方式播出。车站显示子系统主要设备包括：车站交换机、车站服务器、LCD控制器、LCD显示屏、无线AP和天线等。车载显示及监视子系统利用WLAN接入技术，实现列车与地面之间的双向高速实时通信，车载设备通过接收无线传输的信息经处理后实时地在列车LCD显示屏播放。车载显示及监视子系统由车载交换机、无线缓存器、电源适配器、车载无线网桥和天线等组成。我方为了确保XX地铁X号线总体功能的顺利实现，负责与相关系统的接口工作，全面负责接口设计的协调处理及落实、设计联络管理、测试、现场服务安排、接口图纸资料和技术文件管理等方面的工作。我方对各系统间接口的技术参数和性能提出具体要求，使各系统间的接口按照合同文件接口规范处理。我方产品性能和接口问题从产品设计开始就得到重视和解决，并在生产过程中随时处理出现的问题，使接口问题的解决贯穿于整个系统设计、安装、验收的过程。PIS系统与各系统的接口均有详细描述，详见相关接口文件，接口文件说明及编号如下： 乘客信息系统与车辆系统接口文件（CDDT1-TXJC-JKWJ-PIS/RS V01） 乘客信息系统与时钟系统接口文件（CDDT1-TXJC-JKWJ-PIS/CLK V01） 乘客信息系统与网络管理系统接口文件（CDDT1-TXJC-JKWJ-PIS/WG V01） 乘客信息系统与UPS系统接口文件（CDDT1-TXJC-JKWJ-PIS/UPS V01） 乘客信息系统与综合监控系统接口文件（CDDT1-TXJC-JKWJ-PIS/ISCS V01） 乘客信息系统与CCTV系统接口文件（CDDT1-TXJC-JKWJ-PIS/CCTV V01） 乘客信息系统与公安系统接口文件（CDDT1-TXJC-JKWJ-PIS/GA V01）1.3 系统保证目标遵照系统保证计划的情况，在安全、可靠程度、可用程度及可维修程度方面应达至的目标如下：系统名称可靠性可用性可维护性（MTTR）单位：小时单位：故障次数每年每系统单位：百分率响应时间平均故障间隔时间乘客信息系统（PIS）=2499.8%=2=3主要设备平均无故障时间（MTBF）目标如下：序号设备名称平均无故障时间（MTBF）1中心服务器500002无线服务器500003无线控制器500004网络交换机500005中心各类工作站500006中心磁盘阵列存储设备300007视频输入服务器500008数字非线性编辑设备300009数字编辑放像机3000010数字编辑录像机3000011车站视频服务器5000012LCD显示屏3000013LCD控制器3000014无线AP3000015无线缓存器300001.4 故障的定义故障是指任何情况下，导致乘客信息系统或设备不能执行其应有功能。但是不包括那些因为外部输入失效所引起的情况，例如外部的电力供应中断等。PIS系统的故障可以分为控制中心设备故障、车站设备故障、网络设备故障和车载设备故障。控制中心设备故障：如中心数据服务器、数据存储设备、编辑系统设备等，可能引起PIS系统数据丢失，编辑系统无法工作或系统瘫痪。车站设备故障：如视频服务器、LCD控制器、LCD显示器等，可能引起各种信息无法显示或错误显示，影响调度。网络设备故障：包括核心交换设备、车站交换设备、无线控制器、无线AP及天线等，可能引起系统传输中断。车载设备故障：无线缓存器等，可能引起车载显示系统无法显示。2 参考文件和术语2.1 定义及缩写缩写词中文释义英文描述ALARP合理可行的最低限度As Low As Reasonably PracticableATS列车自动监控系统Automatic Train SupervisionDMGXX科技发展有限公司Digital Media Group Co., LtdECR工程变更请求Eeginnering Changing RequestEN欧洲标准European NormETA事故树分析Event Tree AnalysisFAS防灾报警系统Fire Alarm SystemFR故障率Failure RateFRACAS故障报告及修正措施系统Failure Reporting And Corrective Action SystemFTA故障树分析Fault Tree AnalysisHAZOP隐患及可操作性研究Hazard and Operability StudyHL隐患登记册Hazard Log HLR隐患登记册报告Hazard Log ReportsIA固有可用性、其它设备的可用性Inherent AvailabilityIHA接口隐患分析Interface Hazard AnalysisIP互联网协议Internet ProtocolLRU可更换单元First Line Replaceable UnitLLRUs最低级可替换单元Lowest Level Replaceable UnitMTBF平均无故障时间Mean Time Between FailureMTTR平均修复时间Mean Time To RepairOEM原始设备制造商Original Equipment ManufacturerOA运营可用性Operational AvailabilityPDCA质量管理的运作流程Plan，Do，Check，ActPHA初步隐患分析Preliminary Hazard AnalysisPIS乘客信息系统Passenger Information SystemRAM可靠性、可用性、可维修性Reliability, Availability and MaintainabilityRAMS可靠性、可用性、可维修性及安全性Reliability, Availability, Maintainability and SafetyRT响应时间Return TimeRGM可靠性增长管理Reliability Growth ManagementRBD可靠性方块图Reliability Block DiagramSA系统保证System AssuranceSAP系统保证计划System Assurance PlanSAR安全分析报告Safety Analysis ReportSSHA子系统隐患分析Subsystem Hazard AnalysisSSR系统安全报告System Safety Reprot2.2 参考文件文件名称章节XX地铁X号线一期工程乘客信息系统设备采购招 标 文 件（第卷 技术部分）第一章 通用技术要求第6节 系统保证XX地铁X号线一期工程乘客信息系统设备采购合同（技术册）技术附件9 系统保证国际标准EN50126“Railway applications-The specification and demonstration of Reliability,Maintainability and Safety(RAMS)”3 XX地铁X号线一期工程乘客信息系统描述 系统概述XX地铁X号线一期工程乘客信息系统（PIS）是依托多媒体网络技术，以计算机系统为核心，通过设置在站厅、站台、列车的乘客信息显示屏，让乘客及时准确地了解列车的运行状态及安全事项的多媒体综合信息显示系统。是地铁系统实现以人为本、进一步提高地铁为旅客服务质量、加快各种信息（如：乘客行车、安防反恐、运营紧急救灾、地铁公益广告、天气预报、新闻、交通信息等）公告传递的重要设备，是提高地铁运营管理水平，扩大地铁对旅客服务范围的有效工具。XX地铁一号线乘客信息系统（PIS）为地铁站台的信息发布提供了最为灵活、高效、智能、快捷的解决方案。它可以智能地定制多媒体节目，通过光纤网络、系统网络传输到车站子系统，车站播放系统自动按照定制通过各显示终端播放多媒体节目。多媒体数据发布系统中心服务器，可以对系统相关的地铁站台系统进行详尽的定制，灵活、智能地选择所需发布的多媒体节目及其它内容。系统采用实时视频广播的方式到各车站，音视频信息的存储及传送采用MPEG-2流媒体形式，可以保障广播级以上的高清图像质量。XX地铁X号线一期工程乘客信息系统设备项目包括：XX地铁X号线一期工程线路、17个车站、1个控制中心、1个车辆段的乘客信息系统设备及各种安装材料供货及服务，并预留换乘车站和延伸线在技术上和物理上的扩容条件，以及与应急指挥中心、公安通信系统、大屏幕显示系统等的接口条件。 系统结构XX地铁X号线PIS系统分为编播中心子系统、车站（含车辆段）显示子系统、车载显示及监视子系统。编播中心子系统是整个PIS系统的控制中心，主要设备包括：中心交换机、二级交换机、主备中心数据服务器、中心磁盘阵列存储设备、视频输入服务器、接口服务器、无线服务器、无线控制器、发布管理工作站、播出监看工作站、媒体编辑工作站、广告管理工作站、系统管理工作站、无线管理工作站、便携式数字高清DV摄像机、数字编辑录像机、数字编辑放像机、数字非线性编辑系统、录像机、DVD机、有线电视解调器、扫描仪、数字图像传输控制设备、车载视频解码设备、视频编码器、嵌入式数字硬盘录像机、LCD屏、监视器、车载视频控制键盘等。车站显示子系统通过星形光纤通信主干网连接至编播中心。车站服务器和LCD控制器接收来自编播中心的数字多媒体节目（包括乘客服务信息、娱乐、广告节目等）、节目调度表、实时营运信息等，通过LCD显示屏，按用户要求的时间、位置和播出方式播出。车站显示子系统主要设备包括：车站交换机、车站服务器、LCD控制器、LCD显示屏、无线AP和天线等。车载显示及监视子系统利用WLAN接入技术，实现列车与地面之间的双向高速实时通信，车载设备通过接收无线传输的信息经处理后实时地在列车LCD显示屏播放。车载显示及监视子系统由车载交换机、无线缓存器、电源适配器、车载无线网桥和天线等组成。 系统功能 编播中心子系统编播中心子系统负责PIS系统的乘客信息（一般或紧急状态下的运营服务、安全信息）、公共信息（广告、实时新闻、天气预报等外部信息）的制作、接收和发布；将制作好的播放列表及媒体文件素材信息通过传输网络下发到车站或车载设备，发布信号满足高清标准；集中定义和管理全系统各类型和级别的用户所拥有的操作权限；全面监视系统运营，监控系统设备的状态。 车站显示子系统车站显示子系统主要负责从编播中心接收发布的内容信息，通过车站交换机和LCD控制器对本车站所有LCD播放信息显示播放满足高清信号标准，并进行统一的控制和管理。通过车地无线局域网为车载系统转发来自编播中心的内容信息，并将车载系统的监控信息上传到编播中心，同时监视本站系统运营、监控本站系统设备的状态。 车载显示及监视子系统车载显示及监视子系统主要负责无线局域网设备接收编播中心发布的信息内容，通过车载LCD控制器进行解码后，在本列车的所有LCD显示屏上实时播放。同时，车载设备利用无线局域网通道将车上监视图像传递到编播中心及地铁公安分局。4 RAMS工程管理组织及描述4.1 组织架构根据XX地铁X号线一期工程乘客信息系统的具体情况以及合同文件的需求，本公司的系统保证计划组织结构采用XX科技发展有限公司的项目管理模式，本公司将指定专职项目经理，实行项目经理负责制，接受业主各项指令和要求，并加以监督和落实，整个项目组织机构全面负责本工程的系统保证。组织机构中的具体负责人员除了XX科技发展有限公司的成员，还包括网络分包商的系统保证工程师，并指派固定的人员对相关的负责人给予技术上的支持。本章节是确定系统保证计划重要的成功要素，可以适用于本项目的工程施工和调试、试运行阶段。系统保证计划的整个人员组成结构如下所示： 4.2 架构与功能的关系在XX科技发展有限公司的工作方法中，一个强大的项目管理队伍对于这样一个复杂的工程项目是至关重要的。因此，项目管理是保障系统保证计划的重要因素，真正涉及到项目的开端，以确保工程、施工、测试和维护之间的一致性。系统保证计划的组织结构与项目管理的组织结构相同，项目管理的人员对系统保证计划负责。项目组织机构中的系统保证计划机构提供强大的系统保证管理能力，通过设立系统保证工程师、技术管理、现场服务等机构提升不同队伍之间紧密的关系，从而保障系统保证计划顺利进行。4.3 沟通沟通是成功的一个重要要素，不同的工作位置上的协调可以确保始终在一个工作中心内及项目所有阶段的工程质量和一致性。由于这个原因，本公司在整个项目周期中从唯一的运行部门提供全部系统保证计划管理，易于协调和沟通。我公司系统保证计划组织结构提供接口管理有利于开拓与各个外部专业的沟通，确保工程施工、设计符合业主的要求。内部沟通的途径，主要是由项目经理每个月召开一次会议，讨论系统保证工作进度、问题及改善行动。根据工程进度的具体情况，可以相应的增加会议的频率。平常主要以电子邮件或电话的形式进行沟通。系统保证工程师通过召开系统保证计划评审会来分配具体的工作任务，并且根据系统保证计划的进度需要，不定期的举行相关的会议，并形成会议纪要。下面所列出的是一些会议议程的建议： 项目计划-详细描述工作将如何实现； 评审所有的规格、指标、图表等； 详细的系统保证计划； 系统保证计划的人员安排； 项目管理的结构、方法以及负责人；系统保证工程师与业主的沟通采用不定期的方式，通过电话、会议或邮件的方式。可以在例会中加入系统保证的内容，与其他内容的会议一起召开。系统保证计划人员联系方式：4.4 角色及职责整个系统保证计划由项目经理直接领导，同时，公司各相关部门将在各个层面对项目管理团队给予大力的支持。u 项目经理项目经理负责系统保证计划的实施，确保所需的系统保证工作按照系统保证计划进行。项目经理由XX科技发展有限公司人员担任，负责项目的系统保证计划，并负责与业主的联系，了解业主需要和期望的主要接口及其它相关问题。项目经理保证系统保证计划的实施且及时完成，控制项目进度和预算，从而优化资源配置，监控并指导项目执行情况，定期作出进度报告。项目经理对系统保证计划的结果负责，是整个项目的核心人员。 主要职责： 编写相关技术文件； 落实内部系统接口的实施并配合业主协调与其它各个专业系统接口的联系，同时采取灵活措施保证工程质量符合技术要求并且满足关键技术里程碑； 保障安全和质量流程得到较好的贯彻执行； 做好阶段性汇报并定期召开项目审核会议； 项目总结，并进行评定； 监察系统保证工作的进度情况； 监察供货商的系统保证落实情况； 审核提交的相关技术文件； 定期和有关工作单位进行会议、讨论系统保证工作的成效及相关问题； 对项目经理的资质要求： 具有多年地铁工程管理的经验； 在类似工程中担任过本职，对系统保证有较深刻的理解； 在组织、决策方面有丰富的工作经验； 项目经理在整个项目实施过程中对系统保证计划进行总体性的协调管理； 项目经理简历表：u 技术总负责人（总工程师）总工程师负责系统完整性设计、相关技术接口的协调、完整性以及各个设计阶段和采购阶段、联调阶段的系统保证计划协调。 主要职责： 在项目经理的领导下，全面负责项目部技术方面的系统保证工作； 负责贯彻执行技术法规、标准和技术性作业指导书，制定施工项目技术管理制度来保证系统保证计划的顺利实施； 与相关设计人员熟悉图纸，并组织按上级批准的系统保证计划来施工； 负责全线网络系统联调期间的系统保证； 组织实施系统保证计划； 负责工程中各项竣工资料的系统保证情况的签证、收集、整理、并汇总上报； 定期召开技术审核会议确保满足技术要求，与项目各方之间交流各个技术方面的系统保证问题； 对总工程师的资质要求： 具有多年地铁工程项目的经验； 在类似工程担任过本职，对系统保证有深刻的理解和专业性知识； 在组织、实施等方面有较丰富经验； 总工程师简历表：u 系统保证工程师系统保证工程师负责所有的系统保证活动，直接对项目经理负责所有系统保证方面的相关工作，担负所有安全、可靠性、可用性和可维护性（RAMS）问题的总结与归纳工作。 主要职责： 负责评审并向业主提交所有系统保证方面的相关文件； 审阅设计人员提交的RAMS设计文件，并提交给项目经理和业主审核； 乘客信息系统的系统保证工作及提交的系统保证相关文件； 定期和业主进行会议、讨论系统保证工作的进度及有关问题； 系统保证文件的编制及更新； 隐患登记册的制定及编写更新； 进行安全验证； 故障报告及纠正措施系统(FRACAS)； 记录及分析在试运营/质保期阶段发生的故障，报告RAM表现及总结RAM目标是否达到设计要求； 进行系统保证审核； 对系统保证工程师的资质要求： 具有多年地铁工程项目的经验； 在类似工程担任过本职，对系统保证有深刻的理解和专业性知识； 在组织、实施等方面有较丰富经验； 系统保证工程师简历表：u 技术管理工程师技术管理工程师主要负责在项目执行的过程中技术方面的指导和配合工作。 主要职责： 协助工程师做好各子系统系统保证计划的技术工作； 制定各子系统施工的系统保证技术措施； 负责工程技术，解决在施工过程中出现的技术问题，确保工程达到系统保证计划的要求； 起草系统保证计划，并按批准的计划实施； 负责乘客信息系统各子系统的调试； 对技术管理工程师的资质要求： 具有多年地铁设计、施工管理、施工配合和系统保证计划等方面的经验； 在类似工程项目中担任过此职务； 熟悉该系统国内、外技术发展状况； 熟悉该系统的国家有关技术标准； 技术管理工程师简历表：u 制造管理工程师制造管理工程师主要监督原材料采购和设备的生产制造过程，保证这个阶段的系统保证计划顺利实施。 主要职责： 跟踪定单发货情况并有相关文件记录，对材料位置和状态写周报，确保按照总时间计划表设备发货； 准备工厂验收测试计划； 安排保险事宜； 负责货物文档资料； 准备包装清单； 对制造管理工程师的资质要求： 具有类似设备的生产管理经验； 在类似工程项目中担任过本职务； 制造管理工程师简历表：u 现场管理工程师现场管理将由一个完整的小组组成，现场管理负责工程现场的系统保证，核对现场接口条件与设计的一致性，检查设计文件的完整性，施工过程中系统保证问题的协调与处理。同时现场服务管理负责对现场设备的安装、督导、设备试验、调试、设备维修等工作进行系统保证管理并提供相应的技术支持，工程现场的勘测。 主要职责： 监督测试和现场调试工作，负责执行现场的系统保证计划； 同施工单位项目管理协调沟通关于系统保证的问题； 协调与安装、调测、劳动维护方面的系统保证活动； 协调现场各种子系统供货商的系统保证计划； 对现场管理工程师的资质要求： 具有地铁设备施工、安装督导等方面的系统保证经验； 在类似工程项目中担任过本职； 现场管理工程师简历表：u 质量管理工程师质量管理人员负责定义、审核、评估和实施项目的质量计划，保证项目执行期间遵守本公司的质量流程，配合业主就项目中的各种事件进行调查。 主要职责： 控制危险材料的物料安全清单并确保其使用性； 定期提交质检记录,汇报项目相关事件； 同系统工程师,专业工程师一道对各个子系统进行厂验； 确保在整个项目周期内对质量问题的有效沟通； 质量管理工程师简历表：5 系统安全分析及方法5.1 系统安全5.1.1 隐患分析隐患分析由系统保证小组成员和系统保证工程师进行隐患分析，隐患分析的目的是要系统综合地鉴别和评估潜在的危险，将各自的缓解措施纳入到设计中。 主要隐患清单见附件6，隐患登记册样式见附件2。（1） 初步隐患分析 (PHA)作为进一步隐患分析的基础，初步隐患分析（PHA）以隐患即操作性研究(HAZOP)的形式进行，鉴别与合同早期阶段的乘客信息系统设计有关的高危险性，并评估在合同早期与系统有关的危险和风险，并为消除鉴别到的危险，或将它们相关的危险控制在可接收的水平所必需的推荐活动。（2） 子系统隐患分析（SSHA）子系统隐患分析（SSHA）跟在初步隐患分析（PHA）之后，但是在子系统水平进行，子系统信息与子系统的实际设计有关。除了确认子系统符合明确的可靠性、可用性、可维护性及安全性目标之外，要进行子系统隐患分析程序（SSHA）以鉴别和评估与子系统有关的危险及推荐适当的风险降低措施。（3） 接口隐患分析接口隐患分析程序跟在初步隐患分析之后，与其它系统分包商共同完成。综合地鉴别其它专业系统与乘客信息系统接口有关的危险。评审分析其它外部接口分包商进行的接口隐患分析，确保所有接口危险的写入。（4） 操作隐患分析操作及支持隐患分析跟在初步隐患分析之后，对影响系统安全的所有操作和支持程序进行分析判断。评审本系统开发的相关操作和支持程序，以鉴别引入到操作和支持系统中的危险，并评估用于消除和控制鉴别出的危险操作和支持程序是否适当。对于进行操作的系统管理人员，采用图形界面和图表界面。虽然界面风格不一样，但设计原则是一致的。首先，图形系统能满足所有应用的要求，方便地切换各种应用的图形，显示各种应用的数据。其次，图形系统能识别各种标准的图形格式，使用户操作更加方便。PIS的人机界面采用同样的设计原则。在同一人机界面中，所有的菜单选择、命令输入、数据显示和其它功能将保持风格一致性；对所有可能造成损害的动作，要求操作员确认后才执行有关命令；设置不同权限的管理员，只有具有相应权限的管理员才能凭借管理员帐户和密码进入；提供适时的用户帮助信息。5.1.2 隐患分析程序隐患分析流程图如下：（1） 隐患识别参考由业主提供的一份隐患记录及一份主要隐患清单，然后透过一个隐患及可操作性研究(HAZOP)完成。（2） 风险等级评估所有隐患按最初制定的风险矩阵进行风险等级的评估，风险等级评估按照附件1的格式进行。（3） 减轻措施的制定 设计或安装控制的减轻措施安全工作组根据以下原则定期检查隐患登记册上的隐患解决工作的进度： 设计完成前，系统保证工程师必须解决所有需要做出设计变更的隐患事项； 开始施工前，系统保证工程师必须解决所有R1 及R2的隐患事项； 开始进行受安装隐患事项影响的工作前，现场负责人必须实施控制安装隐患事项的所有减轻措施。 过程控制的减轻措施 初步运营阶段前安全工作组结束所有需要特定运营及维修过程控制的运营隐患事项，且必须得到买方的同意。 在完成合同前要将所有与合同有关的危险确定到接受水平。如果到那时还没有确定危险，要提供限制及建议。（4） 隐患登记及审查由设计师进行隐患分析，RAMS专家进行技术指导。最后汇总建立隐患登记册，为隐患分析中鉴别到的危险、提供一个存放处，隐患登记册登记的危险作为设计师设计的依据开展设计，在设计中逐条进行落实，并通过内部评审追踪鉴别的危险，为评审和监测危险提供方法。安全工作组负责监督检查隐患登记册中隐患管控单位的实施，并负责在生产过程中的实施，未符合的事项进行跟踪记录，直到完成任务规范如下：时间安排在PHA完成后首先建立频率发现新隐患时并在隐患解决进程中按需更新。责任系统保证工程师负责综合记录保持，指出隐患和提出解决方案的一般责任延伸到项目的所有人员。输入初步隐患分析，项目组成员在整个项目实施期间的各种输入。输出隐患登记册，交由业主方进行审核。安全管理过程的关键方面是确认、记录和监控项目寿命周期内发现的所有隐患。减轻隐患包括降低隐患频率的控制措施以及一旦输入隐患模式后降低隐患严重性的措施。考虑系统隐患的控制措施时，要遵照以下步骤： 组合故障安全或影响安全的特征，使系统一发生重大故障就能立即从高损失/风险模式转到低损失/风险模式； 降低故障发生几率，通过增大部件可靠性或提供监控过的冗余部件来实现； 降低故障发生几率，通过采用设备运行的专用规程来实现； 一旦引入了隐患模式，就要使用安全器件来降低损失幅度。该组合应： 确保安全器件不会引起另外的隐患或系统故障； 使用报警设备和系统，使之成为影响安全系统的可听/可视部分，使人们能对其作出响应。 （5） 隐患登记册更新对设计、制造阶段中分析鉴别到的风险（如通过FMECA）也要登录到隐患登记册，进行隐患管理。XX地铁X号线乘客信息系统不断地进行故障统计工作，运行FRACAS系统，对发生的隐患事件登录到隐患登记册，进行隐患管理。5.1.3 隐患结束需要考虑的内容 在设计完成前，所有设计减轻措施必须完成。隐患管控单位须确保业主巳审批有关设计文件，才可确认设计减轻措施完成。 在测试阶段完结前，所有建造减轻措施（例如建造物料、工艺标准、调试、测试、调校、检查、量度等) 必须完成。隐患管控单位须确保业主巳审批有关测试/验收记录，并已达至接受标准，才可确认建造减轻措施完成。 需要由业主负责执行的减轻措施，承包商将于试运营阶段前通知业主继续跟进。 在运营阶段，业主方须跟进： 建立各相关规程； 执行各相关规程，并根据运营情况逐步完善。 加强运营管理 所有隐患的剩余风险必须为R3或R4等级，剩余风险R1等级的隐患不被接受。对于剩余风险R2等级的隐患，如没有减轻措施把风险降至R3或R4等级时，隐患管控单位须连同有关理由/证明，向业主申请批准特许，并须获得业主审核批准。 原先风险R3等级的隐患一般可以接受。若实际可行并合乎成本效益，仍须寻求机会，进行减轻措施，把该类隐患的风险降至R4等级。 原先风险R4等级的隐患均在可接受范围内，在正常情况下，毋需采取额外减轻措施。 业主需对所有减轻措施进行审核批准。5.1.4 隐患的减轻措施隐患的减轻措施，可分为设计、建造、运营及维修四个类别。应以设计减轻措施为首先考虑，其次是建造减轻措施(指设备物料及设备采用工艺标准、测试等)、最后才是运营减轻措施(指运营程序、警告标示、训练等措施)及维修减轻措施(指维修程序、维修计划、训练等措施)。在系统设计和工厂制作的过程中，隐患的减轻措施已经考虑，比如系统的设备情况、线缆的布线规则、系统网络的保护等；在生产过程中，通过严格的过程质量控制和完善的监测机制将设备的隐患等级降低到尽可能低的限度。在系统的设计过程中，我们对重要设备、重要部件采用冗余配置，比如中心数据服务器冗余、核心交换机重要模块冗余、无线控制器冗余等。在系统的设计过程中，我们对系统软件也进行了优化设计，不断提高软件的性能。随着项目的进行，我们将根据系统的需求和业主的需要发布更高版本的软件。在乘客信息系统网络子系统的设计过程中，通过一整套完善而成熟的网络保护机制可以有效降低系统因设备故障带来的损害。网络子系统的安装过程中，通过严格的安装和操作规范将使系统的隐患降低并进一步得到保证。在系统投入运行前，本公司会对具体的系统维护人员进行详尽的维护机能培训，从而可以减轻一般故障的隐患；在系统投入运营以后，系统地通过一个完整的故障处理流程保证隐患减轻的措施。公司的故障管理由低到高分为三个级别。第一级别可以处理一些相对简单的故障，其反应速度最快，也最容易解决；第二级别为系统设备的二线技术支持；第三级别为更高级别的技术支持，例如研发部/技术部门，在实际故障处理过程中，依照故障的处理情况级别逐级提高。在乘客信息系统的运营过程中，如发生故障问题，将分配给第一级别的技术支持，如果第一级别的技术支持不能解决，则将故障问题报告提交至第二级别处理；负责第二级别技术支持的相关部门技术人员根据具体的故障级别决定处理办法并一直负责跟踪到问题得到解决为止；如果故障问题仍不能解决，则递交到研发部门的技术维修中心进行进一步的分析处理。在整个障碍处理过程中，处理的时间、方法等都会完整地记录；二级技术支持不能解决的所有问题都会记录在XX科技发展有限公司特定的故障报告记录中，在该报告记录中，所有问题或缺陷的提交时间、涉及到的设备类型及版本号、项目名称、问题分析、解决时间等详细的内容都会记录在其中。从而形成了比较全面的设备故障信息库，便于比对分析和经验积累。从而极大地降低减轻了系统故障所产生的隐患。在维修过程中，通过业主和XX科技发展有限公司的集中备件库相结合来降低因设备故障造成的隐患，同时通过及时送修或视情况决定的加急返修措施来保证故障的及时修复。5.1.5 安全原则及规范要求的符合性评估及安全验证 隐患分析在设计阶段由系统保证工程师组织各专业组长、负责人进行安全原则及规范要求的符合性评估，这将作为安全分析报告的一部分提交并审核。各专业组长、负责人参照技术规范、安全标准等识别安全功能及特点，逐条进行安全原则及规范要求的符合性评估，按照附件3安全原则及规范要求的符合性评估样式填写，由系统保证工程师批准后下发，在制造过程中实施，项目经理负责组织检查、验证，并作为测试及调试测试的一部分进行，论证其一致性。我公司对危害登记册中剩余风险度为R1和R2级的危害以及会导至乘客/员工死亡的危害事项，按系统对照选定的设计、运营安全原则、工业守则或法例进行安全原则及规范要求的符合性评估（包括安全验证）。除此以外，还考虑到危害登记册涉及人员不适、受伤或死亡的危害。专用技术规范的有关安全要求，其它涉及安全及可应用的工业守则、法例及设计标准也应一并考虑。所有在“现在符合状况”栏说明的设计功能/特点须在最后设计阶段完结前落实，而安全验证在测试及调试阶段进行。在设计阶段结束前，再查阅安全原则及规范要求的符合性评估，如有需要，更新有关内容并向业主提交更新的报告。在测试阶段进行所需的安全验证并更新。在测试阶段结束前，确保全部的安全验证已完成，并取得可接受的结果。在试运营前，完成全部安全验证工作，并确认完全符合所需的安全功能/特色要求或标准。安全原则及规范要求的符合性评估及安全验证在最后设计阶段提交报告，并在项目其余阶段进行更新。5.1.6 安全分析报告 安全分析报告包括安全原则及规范要求的符合性评估，在最后设计期间要由系统保证工程师汇总各专业组长、负责人提交的安全分析报告，交由业主审批，在项目其余阶段进行更新。5.1.7 系统安全报告 系统安全报告确认系统是否安全操作，并说明系统是如何实现合同中规定的测试启动时提交系统安全报告。系统安全报告结构及目录见附件4。在最后设计阶段制订和递交系统安全报告草案，在设备安装后的测试阶段前递交正式的最终版本。5.1.8 风险等级评估 所有隐患按业主制定的风险矩阵进行风险等级评估，风险等级评估按照附件1风险矩阵进行。严重性将按照隐患的后果决定，两者必须一致。 进行隐患频率评估时，参照一些已发生的意外、故障数据或使用一些分析工具例如故障树分析、事故树分析等。此外，亦适当利用其它铁路的实际经验及分包商/供货商或国际标准提供的故障数据进行评估或分析。5.1.9 隐患的监控 隐患的监控，可分类为设计、建造、运营及维修四个类别，应以设计的隐患监控为首先考虑，其次是建造的隐患监控（指物料及工艺标准、测试、检查等）、最后才是运营的隐患监控（指运营程序、警告标示、训练等措施）及维修的隐患监控（指维修程序、维修计划、训练等措施）。 在设计阶段结束前，所有设计的隐患监控必须完成。在测试阶段结束前，所有建造的隐患监控必须完成。在试运营阶段前，所有运营的隐患监控（指运营程序、警告标示、训练等措施）及维修的隐患监控 (指维修程序、维修计划、训练等措施)必须完成。对于在项目各阶段发现的新隐患，应对其进行隐患分析，提出减轻措施，并将其补入隐患登记册，更新后报业主审核。在质保期内，我方每月递交监控RAM表现、确定补救措施有效性的临时报告，同时更新隐患登记册。5.2 系统RAM分析及方法系统可靠性、可用性及可维护性最大的目的是评估和预测提供的系统能否满足定下之RAM目标。本公司将提供相关文件，说明如何配置系统架构来满足其总体的可靠性、可用性及可维护性要求，并在后面的工程进展阶段继续更新报告内容。 可靠性、可用性和可维护性分析（RAM）的任务规范如下：时间安排在最终设计阶段进行中，因为此时已能获得各个子系统功能的全面描述。在最终设计阶段完成时必须完成此项内容。频率此报告将在项目的各后续阶段根据需要进行随时更新。责任系统保证工程师负责整项工程的协调工作。实际分析可指派给各专业的工程师完成。输入RAM指标 ；项目设计文件；部件的故障率。输出可靠性、可用性和可维护性分析（RAM）报告，提交给业主进行最终的审核。可靠性、可用性及可维护性分析，将构成潜在设计改进的基础。通过RAM分析，应确定出系统的薄弱环节，并应找出最能改善RAM的解决方案。人为造成因素，可靠性、可用性及可维护性分析中即要考虑到其对系统安全或运行效率的影响。对可能影响系统安全及运营效率的人为因素，本公司会根据有关设计标准作为首要考虑因素。本公司在进行可靠性、可用性及可维护性分析时，还会采用相同或同等设备的故障记录及实际运营故障数据。本公司将提供数据来源，以保证这些资料的真实性和可追溯性。实际的运行数据，将用作RAM计算的依据。5.2.1 基本RAM计算方法（1） 平均无故障时间(MTBF，Mean Time Between Failure)平均无故障时间是指在一段特定的时间内，运行总小时除以这段时间内的故障总数。MTBF被认为和故障率是相应的。任何需要运营或维护人员提供特别协助(即非正常模式)以维特或恢复系统/设备运作的故障，包括所有引至行车延误之假警报或指示错误，均需纳入平均无故障时间的计算之内。外来因素引起之事故，例如：外来电力中断，水淹或员工错误等，则不需纳入计算。但如果事故是由以下原因导致，可以豁免： 战争； 内乱； 可能严重影响基本设备运作的强制性改动； 自然灾害，例如地震、台风、水灾和海啸等； 恐怖袭击； 恶意破坏； 罢工或工业行动； 失去外来电源； 天灾，例如：雷击等； 操作或维护人员的疏忽，人为错误或不遵守操作规程； 公众（包括乘客）的行为，例如：自杀、身体不适等； 因非合同设备导致的事故； 超出运营单位管辖范围的机关所采取的行动，例如：公安部门的行动等。计算公式如下： 平均无故障时间（MTBF）=（2） 平均修复时间(MTTR，Mean Time to Repair)： 在计算矫正维护平均修复时间时，须包括诊断时间、组件修理及替换时间、以及在现场的调整及测试时间在内。运营及/或维护员工到达现场前的反应时间及运营员工在现场的诊断时间则不包括在内。 （3） 平均停机时间(MDT，Mean Down Time)： 将平均修复时间(MTTR)的定义扩展至包括运营及/或维护员工到达现场前的反应时间及运营员工在现场的诊断时间。（4） 运营可用性跟据以下公式计算： 运营可用性 = 5.2.2 RAM分析系统RAM分析最大的目的是评估和预测提供的系统能否满足定下的RAM目标。本公司将在设计阶段提供报告文件，说明如何配置系统架构来满足其总体RAM的要求，并在后面的工程进展阶段继续更新报告内容。同时，也将业主要求的RAM目标分配到每一个子系统，作为子系统的RAM目标并提交买方批准。可靠性、可用性和可维护性分析（RAMS）的任务规范如下：时间安排在最终设计阶段进行中，因为此时已能获得各个子系统功能的全面描述。频率一次性分析，以一个一个的子系统为基础进行。此报告将在项目的各后续阶段根据需要进行随时更新。责任系统保证工程师负责整项工程的协调工作。实际分析可指派给各专业的工程师完