功能安全评估第二部分_安全评估的执行_报告和后续跟踪_第1页
功能安全评估第二部分_安全评估的执行_报告和后续跟踪_第2页
功能安全评估第二部分_安全评估的执行_报告和后续跟踪_第3页
功能安全评估第二部分_安全评估的执行_报告和后续跟踪_第4页
功能安全评估第二部分_安全评估的执行_报告和后续跟踪_第5页
已阅读5页,还剩4页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

18仪器仪表标准化与计量 2009 . 4 Control Tech of Safety & Security 功能安全评估 第二部分:安全评估的执行、报告和后续跟踪 Functional Safety Assessment Part 2:Performing, Reporting and Following up of the Functional Safety Assessment Stuart Nunns1 曾硕巍2 (1.ABB 有限公司 2.ABB (中国)有限公司,北京市 010020) Stuart Nunns1 William Zeng2 (1.ABB Limited 2.ABB (China ) Limited,Beijing 010020) 【摘 要】 【关键词】 Abstract: Functional Safety Assessments (FSAs) are undertaken in addition to the traditional safety lifecycle activities of verifi cation, validation and functional safety audits. These safety lifecycle activities are typically planned and executed directly by the Safety-Related Systems project team implementing phase(s) of the safety lifecycle. The purpose of a FSA is to independently ensure that functional safety has been achieved within the specifi c scope of supply for the organization(s) in the context of the safety lifecycle. In this second part of the guide, we describe the methodology for performing the functional safety assessment including a three stage approach aligned to the safety lifecycle. In addition, the reporting of the functional safety assessment and follow-up activities are described. Key words: FSA SRS FSMS SEC SIL 功能安全评估(FSAs)是在传统的安全生命周期活动如验证,确认和功能安全审核之外进行 的。 这些安全生命周期活动通常直接由安全相关系统的项目团队在执行阶段进行计划和实施。 功能安全评估的目的在于独立地确保功能安全在机构特定的供货范围内得以实现. 在本指南的第 二部分我们着重讨论执行功能安全评估所采用的与生命周期相吻合的3阶段方法论, 并对功能 安全评估的报告和后续跟踪作了描述。 功能安全评估 安全相关系统 功能安全管理系统 安全执行中心 安全完整性等级 1 简介 对于很多读者来说,功能安全评估(FSA)是功 能安全领域中的一个新话题。甚至就那些阅读过并 且理解IEC 615081和IEC 615112关键特性的读者, 可能也不是非常熟悉FSA活动的具体细节;并意识到 FSA是一个强制性的(应)要求如果某某想要声 称对 IEC 61508的合规,或者在实际当中已经执行了 FSA并从中受益。 FSA是在传统的安全生命周期活动如验证、确认 和功能安全审核之外进行的。这些活动通常直接是由 安全相关系统项目团队在执行阶段进行计划和实施。 实施FSA的特定目的在于确保功能安全在机构特定的 供货范围内已经实现预期的目标。对一个典型的系统 集成商而言,其供货范围仅是端到端安全相关系统的 逻辑解算器子系统部分。对一个负责工程,采购和施 工(EPC)的公司来说,这通常是端到端安全相关系 统,包括输入子系统、逻辑解算器子系统和最终元件 (输出)子系统。 IEC 61508和IEC 61511都有专门针对FSA的章节 条款,即IEC 61508中第1部分第8章和IEC 61511中第 1部分第5.2.6.1节。然而,它们在方法和建议上存在 差异那些寻求实施FSA的人和/或机构需要对此 进行审慎的诠释和理解。 实现FSA要求员工具有高 水准的资质,并通常有较强客观性,尤其是当应用于 安全生命周期的早期阶段。FSA用来评估是否采用适 当的方法、技术和流程来取得预期的功能安全。 本指南包括两部分,向读者提供一个为分布在 全球的ABB安全执行中心(SEC)所使用的关于FSA 过程方法论和FSA报告机制的详细内容。这些SEC都 收稿日期:2009-07-30 作者简介: Stuart R. Nunns,ABB公司过程自动化部安全领先执行 中心的首席顾问, TV功能安全的专家,在油气、化工、钢铁、 电力生产等领域具有36年的自动化和安全从业经验。目前在ABB 公司领导一个全球工作项目,致力于在全球建立一系列经TV认 证的ABB安全执行中心。Nunns是IET功能安全专业网络执行小组 成员和InstMC安全委员会成员,发表过多篇相关论文,担任国际 安全系统工作组领导。 曾硕巍,就职于ABB (中国) 有限公司,任自动化系统亚太区中 国部经理. 在ABB公司从事工业自动化产品的开发,应用及市场 推广工作超过11年, 曾代表瑞典ABB在瑞典国家电工协会(SEK TK65)和国际电工协会 IEC SC65B/WG7 出任专家。近年来积 极介入功能安全产品的推广及功能安全管理系统的建立工作。 现在代表ABB中国在一系列专业技术委员会和技术协会任职(如 SAC/TC 124等)。 19仪器仪表标准化与计量 2009 . 4 安全控制技术 有符合IEC 61508的功能安全管理系统(FSMS),并 正在逐步通过TV莱茵(TV Rheinland)的认证。 他们为客户实施以逻辑解决器子系统的集成及配置为 重点的安全系统解决方案。SEC执行FSA是合规性和 取证的要求。有关ABB在 SEC功能性安全管理系统 (FSMS)的具体内容, 请参见文献4。 本指南的第二部分描述了执行功能安全评估的 方法,包括按照安全生命周期进行的三个阶段。此 外,还描述了功能安全评估的报告和后续跟踪。 2 执行FSA 如下步骤构成执行FSA过程的完整流程: * 审查日程和评估程序 * 审查安全生命周期计划,及关于此计划的: 验证、确认和测试安排的审查; 文档化规程的审查; 安全要求规范中的要求是否完成,特别是它 应包括功能性和声称SIL的审查; 每个安全功能的SIL是否达到其目标SIL的审 查; 验证和确认活动完备性的审查; 应用于开发过程中的系统/设备的配置管理 系统实施的审查; 经使用验证声明的审查; 环境影响(含EMC防护)的审查; 资质能力的审查。 在初步FSA、设计FSA和最终FSA阶段期间,核 对清单的使用可以帮助集中在需覆盖的关键区域的评 估团队。这些核对清单: * 保证安全系统的必要文档按照项目程序生成, 并且评估者可使用此文档; * 保证在设计或规程中评估标识的不足可通过这 样的方式修正,即将改动限制在单个阶段/子阶段, 并对其它区域的影响最小; * 作为对系统各方面的关键评价的促进因数,而 非拟定特定要求。评估者必须在关于评估特定系统的 问题应用中做出判断; * 根据来自关于其有效性和覆盖面的FSA的反馈 进行更新。 对于初步FSA,提取采用由安全领导资质中心 (SLCC)开发和使用的如下核对清单。 通过对项目安全生命周期管理计划(SLMP)的 评估,可验证如下内容: * 是否清楚定义所有功能团队、部门和供应链机 构? * 是否明确规定单个项目的责任和义务? * 是否有清楚定义的安全生命周期模型,并且对 于项目的安全相关系统供货范围是否全面而充分? * 安全生命周期模型是否覆盖验证、确认和测 试?它们是否定义? * 适用规程是否充分对应SLMP活动和阶段? * 是否清楚标识所有项目特定规程和工作说明? * 是否清楚说明所有用户定义限制? * 是否清楚标识功能安全审核和评估? * 是否有项目特定独立验证功能?是否清楚定义 其参考条款?项目团队是否了解验证要求? * 是否有映射到SLMP的项目计划? * 是否对资质管理和评估有清楚定义的规程和程 序?员工是否具有项目资质能力?是否有处理缺陷的 计划? * 外部标准和规章是否清楚标识为SEC FSMS的 组成部分和安全相关系统(SRS)的相关部分? * 如何监控和完成这些规章和标准的合规性? * 是否标识客户指定的规程、方法、技术和工 具?是否清楚规定将它们包含到项目中的方法? * 是否在审查、批准、验收和独立性方面清楚规 定客户角色? * 是否规定其它第三方机构/ABB机构和它们在 功能安全方面的角色及职责? * 是否规定扩展方法和不合规项处理方法? * 是否有代替通知项目成员其功能安全方面职责 的途径? * 项目交付内容是否适于安全相关系统的范围和 复杂程度? * 项目活动是否与SLMP里程碑和阶段一致? * 对于安全生命周期的各阶段,是否定义输入、 输出和验证活动? * 是否有指导设计审查的工程流程? * 是否有一个有效的系统来保证涉足项目各方之 间的协调一致? * 是否有生成和维护关于项目的足够文档的规程 /方法,例如是否充分设计并利用文档管理系统? * 是否清楚标识关于文档的属性(标题、名称、 内容范围、索引、修订、版本、批准、完成等)? * 是否有贯穿项目的变更管理规程? * 是否有对材料、工艺、质检和测试的规范和规 程? * 是否清楚说明合规认证的要求及其条件? 设计FSA在FDS完成之后执行的,如下是所使用 的核对清单摘要: 通过对项目设计(功能和设计规范)的评估, 验证如下内容: (需要注意的是,若SRS中缺少设计标准,确保 20仪器仪表标准化与计量 2009 . 4 Control Tech of Safety & Security 声明所有假设条件并记录其基本原理) * 是否清楚定义关于安全相关系统边界的供货范 围? * 安全功能是否已按工厂区域逻辑分组? * 硬件的性能问题是否业已考虑 * 对于每个所标识的事件,其过程安全状态的定 义是否已经确认? * 是否已清楚定义强制原则? * 是否已规定投票和降级要求? * SIS对过程和系统失效的响应是否业已考虑? * 是否已确认安全相关系统的过程输入及其跳闸 点? * 是否已确认过程变量的常规操作范围及其操作 限制? * 是否已确认安全相关系统的过程输出及其动 作? * 是否已确认过程输入和输出间的功能关系,包 括逻辑、数学功能和任何必需前提? * 是否已确认选择去电跳闸或是带电跳闸? * 是否已确认对人工停机、跳闸复位和强制的要 求? * 是否已确认断电时安全相关系统采取的动作? * 是否已确认使过程进入安全状态的安全相关系 统的响应时间要求? * 是否已确认对明显故障的响应动作? * 是否已确认人机界面要求? * 如果在安全相关系统中实现非安全功能,它们 是否被清楚标识? * 是否有针对执行例如顺控、速度和精度控制的 特殊逻辑解算器的要求?它们是否与定义的输入和输 出一致? * 安全平台的选择是否适合安全功能要求?是否 清楚定义考虑的基础?是否清楚定义该系统结构?是 否有支持该安全平台的安全手册、可靠性数据手册 等? * 应对功能安全和完整性做出怎样的假设?如何 记录这些假设,例如FDS中是否已包含一个假设列 表? * 是否已按照安全相关系统形式审查FDS?是否 已按照设计审查规程和独立性等级对其审查? * FDS能是否溯源到安全相关系统? * FDS的规划是否足够保证适当而完整的功能测 试? 通过对项目测试计划(测试计划、测试规范) 的评估,验证如下内容: * 是否规定测试(功能、黑盒、白盒)方法和原 理,并符合安全生命周期阶段和活动,即测试计划? 通过对项目技术和方法(技术和方法规范)的 评估,验证如下内容: * 是否规定技术、工具和方法,并且它们是否合 适?例如: * 是否有对这些工具的描述? * 哪种输出需要由这些工具生成? * 哪些人需要接收这些输出? * 由谁负责评估适用性和维护这些工具? 最终FSA在现场验收测试(FAT)之后执行。如 下是使用的核对清单摘要: 通过对项目SIL完成情况报告的评估,验证如下 各项: * 是否已确认各安全功能所需的SIL? * 是否对系统的、结构的SIL目标失效量有清 楚的认识和定义? * 是否已确认各安全功能的操作模式(低要求或 连续/高要求)? * 是否已规定对于所有安全功能的检验测试间 隔? * 是否已规定平均修复时间(MTTR)? * 是否记录安全功能目标完成方面的任何限制? 是否描述该分析和原理? * 体系结构元素方面建模的安全功能是否用于执 行SIL完成情况报告中的各安全功能? * 是否清楚确认第三方提供的所有其他元素?是 否规定SIL数据要求? 通过对项目操作和维护手册的评估,验证如下 内容: * 是否已确认用来保证承担的硬件检验测试的要 求、限制、功能和设施? * 是否已确认极限环境条件? * 是否已确认EMC要求? * 是否已确认在安全相关系统或过程的维护和修 改期间的维护安全操作? * 是否已确认对于带有最小物理旁路(如跳线) 的安全相关系统设备的功能测试? 通过对验证活动输出的评估,验证如下内容: * 是否已保留所有审查说明?是否实施对文档和 代码审查的适当动作? 是否提供针对变更控制的系统流程的证据?它 是否已正确实施?是否已正确执行影响分析? 核对清单发布时会附带“警告语”,它不应以 僵硬的方式使用,或作为确保已检查足够证据来展示 功能安全业已取得的唯一手段,或如果未能取得,则 作为安全系统和项目中需要补救工作的区域。 21仪器仪表标准化与计量 2009 . 4 安全控制技术 卓有成效的功能安全评估的关键是从涉足项目 的人员中获取证据,而对FSA的广度和深度影响最大 的是来自评估者本身的知识和经验。 FSA评估者核对清单开发的同时,SLCC执行 IEC 61508的详细审查,以确定在FSA期间涵盖了那 些关于过程和关键交付内容的标准相关关键条款,并 作为各FSA阶段中必要检查的最低要求。 此审查的输出产生一组与FSA各阶段相对应的表 格,并实现以下两个目的: 1合规性报告一个记录FSA阶段发现(认 可、有条件认可、否决)的方法; 2用作评估者指南的IEC 61508特定条款和内 容。 这些表格的摘要见表1、表2、表3。 表1 初步FSA符合性报告摘要 项 目 条款目的和要求 建议 认可(A) 否决(R) 有条件认可(QA) 不适用(NA) 2IEC 61508-1, 第6章, 功能安全 的管理 6.1目的 6.1.1确定整体的、E/E/PES的和软件的安全生命周期所有阶段的管理和技术活动。这 些阶段是达到E/E/PES安全相关系统要求的功能安全所必需的。 6.1.2确定人员、部门和机构对整体的、E/E/PES的和软件的安全生命周期各阶段或各 阶段中活动所负的责任。 2.1 IEC 61508-1, 6.2.1 6.2要求 6.2.1为确保E/E/PES安全相关系统达到并保持所要求的功能安全,对整体的、E/E/PES 的或软件的安全生命周期的一个或几个阶段负全责的组织或个人应规定所有的管理和 技术活动,尤其要考虑以下各点: a) 达到功能安全的方针和战略、以及是否达到的评价方法,和为确保安全作业的素 质,在组织内部进行交流的方法。 b) 对整体的、E/E/PES的或软件的安全生命周期各阶段负责执行和复核的人员、部门 或组织的识别(包括有关的发证当局或安全管理机构)。 c) 整体的、E/E/PES的或软件的安全生命周期被实施的阶段。 d) 信息结构化和扩展信息文档化的方法(见第5章)。 e) 用于满足某一规定条款要求所选的措施或技术(见IEC 61508-2,IEC 61508-3和IEC 61508-6)。 f) 功能安全评估活动(第8章) g) 对E/E/PES安全相关系统建议的满意解决和及时跟踪的规程可由危险和风险评估得 出(见7.4)。 表2 初步FSA符合性报告摘要 条 款 章节目的和要求 建议 认可(A) 否决(R) 有条件认可(QA) 不适用(NA) 1IEC 61508-1, 第5章, 文档 5.1目的 5.1.1规定能够有效执行整体安全生命周期、E/E/PES安全生命周期和软件安全生命周 期各阶段所必需的信息,这些信息将被文档化。 5.1.2规定能够有效执行功能安全管理(见第6章)、验证(见7.18)以及功能安全评 估等活动所必需的信息,这些信息也将被文档化。 评估者请注意,初步FSA阶段,寻求证据证明交付内容在SLMP中确定,并且SLMP 自身接受正式检查和批准。 在设计和最终FSA阶段,将检查功能安全审核结果。 1.1 IEC 61508-1, 5.2要求 5.2.1文档中应包括E/E/PES的和软件的以及整体的安全生命周期中各阶段的足够信 息,这些信息是有效执行各阶段和验证活动所必需的。 5.2.2文档中应包括管理功能安全所要求的足够信息(见第6章)。 5.2.3文档中应包括实现功能安全评估所需的足够信息,也包括从任何功能安全评估得 到的结果和信息。 5.2.4除了在功能安全计划编制中已作调整或应用领域标准中已规定外,要文档化的信 息应同本标准各章所述一样。 5.2.5相对于标准的条款,文档应足够充分以便于执行。 5.2.6文档应: 准确简明;让使用者容易理解;能达到预期目的;可存取和可维护。 5.2.7文档或信息集应有指示内容的标题或名称,以及一些形式的检索,以便于访问标 准中所需的信息。 5.2.8文档的结构可根据公司规程和应用领域的工作实践来确定。 5.2.9文档或信息集应有修订检索(版本号),以区别文档的不同版本。 5.2.10文档或信息集应结构化以便于查找相关信息,以及易于识别文档或信息集的最 新修订版(版本)。 22仪器仪表标准化与计量 2009 . 4 Control Tech of Safety & Security 表3 最终FSA符合性报告摘要 条 款 章节目的和要求 建议 认可(A) 否决(R) 有条件认可(QA) 不适用(NA) 3IEC 61508-2, 7.4,E/E/ PES的设 计与开发 7.4.1目的 确保E/E/PES安全相关系统的设计和实现满足规定的安全功能和安全完整性要求(见 7.2)。 3.1 IEC 61508-2, 7.4.2, 一般要求 7.4.2.1考虑7.4的所有要求,并根据E/E/PES安全要求规范(见7.2)设计E/E/PE安全相 关系统。 7.4.2.2 E/E/PES安全相关系统的设计(包括硬、软件的整体结构、传感器、执行器、 可编程电子、嵌入式软件和应用软件等,见图4),应当符合以下a)c)的全部要 求: a) 硬件安全完整性要求包括: 硬件安全完整性的结构约束(见7.4.3.1);和 危险随机硬件失效概率的要求(见7.4.3.2)。 b) 系统安全完整性要求包括: 避免失效的要求(见7.4.4)和系统故障控制的要求(见7.4.5);或 设备“经使用证实”的证据(见7.4.7.67.4.7.12)。 c) 故障检测时对系统行为的要求(见7.4.6)。 7.4.2.3在E/E/PE安全相关系统既执行安全功能又执行非安全功能的地方,除非能够表 明实现安全功能和非安全功能是充分独立的(也就是说,非安全功能的失效不会引起 安全功能的危险失效),否则所有的软硬件都应被视为与安全相关的。只要可行,安 全功能应与非安全功能分开。 7.4.2.4软硬件的要求由拥有最高安全完整性等级的安全功能的安全完整性等级来决 定,除非能够表明不同安全完整性等级的安全功能的实现是充分独立的。 7.4.2.5在要求安全功能之间相互独立(见7.4.2.3和7.4.2.4)时,在设计时以下几条应 文档化: a) 达到独立的方法; b) 方法的合理性证明。 7.4.2.6 E/E/PE安全相关系统的开发者应可获得安全软件的要求(见IEC 61508-3)。 7.4.2.7 E/E/PE安全相关系统的开发者应复审安全软硬件的要求,以保证其已充分规 定。E/E/PE的开发者应特别考虑: a) 安全功能 b) E/E/PE安全相关系统安全完整性要求; c) 设备与操作员界面。 7.4.2.8 E/E/PE安全相关系统设计文档应规定在E/E/PES安全生命周期各阶段中为达到 安全完整性等级所必需的技术和措施。 7.4.2.9 E/E/PE安全相关系统设计文档应证明,为形成满足要求的安全完整性等级的集 成集所选择的技术和措施的合理性。 7.4.2.10在设计与开发活动中,应认识、评估和文档化所有软硬件相互作用的重要意 义(如相关)。 7.4.2.11设计应基于子系统分解的方法,每一个子系统有规定的设计和系列集成测试 (见7.4.7)。 7.4.2.12带多路输出的子系统,有必要确定由E/E/PE安全相关系统失效引起的一些 输出状态的组合是否能够直接引发危险事件(如用危险与风险分析来确定,见IEC 61508-1的7.4.2.10)。本条建立后,对输出状态的组合的预防措施应被视为在高要求 或连续操作模式下工作的一个安全功能(见7.4.6.3和7.4.3.2.5)。 7.4.2.13所有的不见应尽可能降额(见IEC 61508-7附录A的A.2.8)使用。在其极限值 下使用任意不见的合理性证明应文档化(见IEC 61508-1的第5章)。 3.2 IEC 61508-2, 7.4.3,硬 件安全完 整性要求 3.3 IEC 61508-2, 7.4.3.1, 硬件安全 完整性结 构约束 见SIL实现规程与SIL实现报告框架与IEC 61508-2;7.4.3.1.1-7.4.3.1.6. (3BGB 000390 D0005(SIL实现报告框架)3BGB 000385(SIL实现规程) 23仪器仪表标准化与计量 2009 . 4 安全控制技术 3.4 IEC 61508-2, 7.4.3.2, 估算由于 随即硬件 失效引起 安全功能 失效的概 率的要求 见SIL实现规程与SIL实现报告框架与IEC 61508-2;7.4.3.1.1-7.4.3.1.6. (3BGB 000390 D0005(SIL实现报告框架)3BGB 000385(SIL实现规程) 3.5 IEC 61508-2, 7.4.4,避 免失效 的要求 7.4.4.1应使用一组恰当的技术和措施,用于在E/E/PE安全相关系 统硬件的设计和开发期内防止引入故障(见表B.2)。 7.4.4.2根据所需的安全完整性等级,所选择的设计方法具有的特性应有助于: a) 透明性、模块化和控制复杂性的其他特性。 b) 清晰和精确地表述: 功能性; 子系统接口; 排序和时间关联信息; 并发性和同步化。 c) 信息的通信和清晰、准确的文档化。 d) 验证和确认。 7.4.4.3为保证E/E/PE安全相关系统的安全完整性能保持在所 需的等级,在设计阶段就应将维护要求规范化。 7.4.4.4如适用,应使用自动测试工具和集成开发工具。 7.4.4.5设计期间,应编制E/E/PE的集成测试计划。编制测试计划的文档应包括: a) 所执行测试的类型和所遵循的规程; b) 测试环境、工具、配置和程序; c) 测试是否通过的准则。 7.4.4.6设计期间,根据开发者提出的前提条件可执行的那些活 动,应该与在用户立场上所要求的活动加以区分。 3.6 IEC 61508-2, 7.4.5,控 制系统故 障的要求 7.4.5.1为控制系统故障,E/E/PES的设计特点应使得E/E/PE安全相关系统能容许: a) 如果不能排除硬件设计故障的可能性(见表A.16),硬件中的任何残余设计故障; b) 环境应力,包括电磁干扰(见表A.17); c) EUC操作员造成的失误(见表A.18); d) 软件中的任何残余设计故障(见IEC 61508-3的7.4.3及相关的表); e) 任何数据通信过程中产生的错误和其它影响(见7.4.8)。 7.4.5.2在设计和开发活动中应考虑可维护性和可测试性,以 便在最终的E/E/PE安全相关系统中实现这些属性。 7.4.5.3 E/E/PE安全相关系统的设计应充分考虑人员的能力和局限性, 并应适合分配给操作者和维护人员的行动。所有接口的设计应根据良 好的人员操作习惯并应适合操作者的认知能力和培训水平,例如对于 批量生产中的E/E/PE安全相关系统,操作者只是公众的一员。 3.7IEC 61508-2, 7.4.6 (7.4.6.1 7.4.6.3), 故障检测 时对系统 行为的要 求 本节的要求主要针对终端用户,然而一些问题可能是相关的。例如,终端用户要求的信 息是否充分文档化? 3.8IEC 61508-2, 7.4.7, E/E/PES 实现的要 求 7.4.7.1根据E/E/PES的设计来实现E/E/PE安全相关系统。 7.4.7.2被一个或多个安全功能使用的所有子系统都应作为安全相关子系统进行标识和文 档化。 7.4.7.3对于每一个安全相关子系统(见7.4.7.4)应提供下列信息: a) 功能的功能性规范和安全功能使用的子系统的接口; b) 在危险失效可由诊断测试检测出的情况下,在任何模式下能引起E/E/PE安全相关系统 危险失效的估算失效率(由随机硬件失效引起)(见7.4.7.4); c) 在危险失效用诊断测试检测不到的情况下,在任何模式下能引起E/E/PE安全相关系统 危险失效的估算失效率(由随机硬件失效引起)(见7.4.7.4); d) 为保持由于随机硬件失效引起的估算失效率的有效性,子系统应遵循的环境限制; e) 为保持由于随机硬件失效引起的估算失效率的有效性,子系统不得超过的寿命限制; f) 定期检验测试和/或维护要求; g) 根据附录C得出的诊断覆盖率(需要时见注1); h) 诊断测试间隔(需要时见注1); i) 诊断发现故障后为能推导出平均恢复时间(MTTR)所必需的附加信息(例如修理时 间); 24仪器仪表标准化与计量 2009 . 4 Control Tech of Safety & Security 3 FSA报告及文档化 完成评估后, FSA领导评估者将报告提供给: * 安全项目领导工程师 * 项目经理 * SEC经理 * FSMS质量经理 * UK SLCC经理。 本报告至少包括: * 评估范围的描述 * 系统和系统应用领域的简要描述 * 所有文档和所检查的文档版本号的列表 * 所有用于评估的参考材料列表 j) 根据附录C确定的、能推导出子系统用于E/E/PE安全相关系统中的安全失效分数 (SFF)的所有信息; k) 子系统的硬件故障裕度; l) 为避免系统失效,应遵循的对子系统应用的任何限制; m) 某个安全功能所能声明的最高安全完整性等级,该安全功能使用子系统时,应基 于: 在子系统硬件和软件的设计和实现过程中为防止引入系统故障所使用的技术和措施 (见7.4.4.1和IEC 61508-3的7.4)。 使子系统能容许系统故障的设计特性(见7.4.5.1); 注:对于那些经使用证实的子系统不作要求(见7.4.7.5)。 n) 为了使E/E/PE安全相关系统的配置管理符合IEC 61508-1中6.2.1的要求,需要识 别子系统硬件和软件配置的所有信息; o) 证明子系统经过确认的文档化证据。 7.4.7.4由于随机硬件失效造成的子系统的失效的估算失效率(见7.4.7.3b)和c))可: a) 利用公认的、来源于工业的部件失效数据,通过设计失效模式和效应分析来确 定; b) 或基于以往在类似环境条件下使用子系统的经验来确定(见7.4.7.9)。 7.4.7.5对于认为是经使用证实的子系统(见7.4.7.6),不要求提供用于预防和控制系统 故障的技术和措施的有关信息(见7.4.7.3m)。 7.4.7.6对于以往开发的子系统,只有在功能性规定明确、有充分文档依据表明子系统的 具体配置此前确实应用过(使用时的所有失效记录均登记在册,见7.4.7.10)、以及考 虑过任何所需的附加分析和测试(见7.4.7.8)时,才能被认为是经使用证实的子系统。 文档依据应显示E/E/PE安全相关系统子系统的任何失效(由随机硬件和系统故障造成) 的可能性足够低,可以达到使用子系统的安全功能所需的安全完整性等级。 7.4.7.7为了确定任何未被检测到的系统故障的可能性足够低,可以达到使用子系统的安 全功能所需的安全完整性等级,7.4.7.6要求的文档应显示出具体子系统以往的使用条件 (见注)与在E/E/PE安全相关系统中子系统将要经历的条件相同或者非常接近。 7.4.7.8如果以往的使用条件与在E/E/PE安全相关系统内将要经历的条件存在差异,应当 对这些差异加以标识,并结合恰当的分析方法和测试对这些差异进行明确地例示,以便 确定任何未被揭露出的系统故障的可能性足够低,以致可以达到使用子系统的安全功能 所需的安全完整性等级。 7.4.7.9 7.4.7.6要求的文档证据应确定以往子系统的专用配置的使用程度(用工作小时表 示)在统计学基础上足以支持所声明的失效率。最低限度,需要足够的工作时间才能 确立所声明的失效率数据的置信度单边下限值至少能达到70%(见IEC 61508-7附录D和 IEEE 352)。任何工作时间不超过一年的单个子系统在统计分析中不作为计算总工作时 间的一部分。 7.4.7.10在确定是否满足上述要求(7.4.7.6 到7.4.7.9)时,仅考虑以前的将子系统的全 部失效有效地检测和报告的操作(例如,当按照IEC 60300-3-2推荐已收集了失效数据 时)。 7.4.7.11在根据可用信息的广度和深度(见IEC 61508-1的4.1),确定是否满足上述要求 (7.4.7.67.4.7.9)时,应考虑以下因数: a) 子系统的复杂性; b) 子系统对降低风险所起的作用; c) 子系统失效产生的后果; d) 设计的新颖性。 7.4.7.12在E/E/PE安全相关系统中,对“经使用证实”的安全相关子系统的应用只局限于 在满足相关要求(见7.4.7.67.4.7.10)的子系统的那些功能和接口。 * 所有被充分分配和证明的安全功能列表 * 缺少足够支持和判断的安全功能列表,如果存 在的话 * 缺少足够支持和判断的安全声明列表 * 有关功能安全完成情况的考虑或不足的列表 * 要求的用来将评估类别改到认可的动作项目列 表 * 评估者及其相关联系的标识 * 所有涉及评估的安全项目人员及其角色和职责 的列表 * 结果汇总 结果应为以下三种类型之一: 25仪器仪表标准化与计量 2009 . 4 安全控制技术 * 认可(A):有充分证据证明支持目标的相关 要求已经达到。 * 有条件认可(QA):在初步FSA和设计FSA阶 段,没有充分证据证明支持目标的相关要求已经达 到。在规定阶段内采用修正动作。在最终FSA阶段, 没有充分证据证明支持目标的相关要求已经达到。在 规定阶段内采用修正动作。没有达到完全认可的原因 应对要求的功能安全没有实质性影响。 * 否决:没有充分证据证明支持目标的相关要求 已经达到。该结论反映了评估者对于功能安全完成情 况的严重关切。它要求安全项目团队的迫切关注和 FSA团队成员的重新评估。 4 FSA的后续跟踪 如果结论为“有条件认可”或“否决”,项目 领导工程师必须向FSA领导评估者、SEC经理和UK SLCC提供一份详细说明要执行的修正动作的计划和 同意完成这些修正动作的期限。 UK SLCC审查所有FSA趋势报告。如需要,UK SLCC更新通用安全生命周期模型,并向所有SEC提 供对功能安全管理系统影响的反馈和建议。 表4 FSA报告表的示例 项目 阶段2 报告编号 A0700016-003 领导评估者 Stuart Nunns 报告日期 2007年8月29日 FSA阶段 最终 参考 设计和计划文档 项目负责人 项目经理 报告(由评估者完成) FSA核对清单项目2,以下报告基于参考文档: 1. 需要参考所有相关文档进行更新SLMP中的变更历史。 2. 项目应保证技术与方法规范审查记录可用,并且技术与方法规范在内部发布。 3. 需要更新项目进度以反映有关交付内容和活动的当前状态。 4. 在项目进度中删除TBA。 5. 安全生命周期模型、流程和交付内容需要明确映射到项目进度,并使用一致的术语。 6. 将模块设计纳入安全DFDS的基本原理需要包含在SLMP中。 7. 文档记录不包含模块设计规范,也需要更新相关术语以保证与进度和SLMP的一致性。 8. 需要更新文档记录以反映所有发布给客户的材料。同样,要求检查所有的传递是否有序进行。 9. 模块测试规范应在测试开始前得到客户批准。 10. 保证所有的传递至少都存于项目库中。 11. 审查所有项目的相关内容,并保证其保存在相应文件和位置中。 12. 审核CAR以停止其活动。 13. 要求更新项目机构,以包括所有指定的项目人员。 14. 至少有3个资质档案缺失。审查并更新资质档案。 15. 保证所有项目人员具有最新的CV和培训记录。这必须包含INOPC资源。 16. 要求参考为何客户同意不提供安全功能;并提供完整描述。 17. 要求使用最新规程重新编写SIL完成情况报告。 18. 必须在每个(通用的)回路上实现SIL完成情况。 19. 项目必须审查并发布技术与方法规范。 20. 项目必须验证并提供技术与方法规范已被应用的证据。 21. 应基于任何测试活动期间进行的项目查询并以书面形式实现影响评估。 22. 对于将来的项目查询,保证“解决方案”方面足够完整。 23. 保证审查所有测试记录的完整性,并将审查记录在测试文件夹内。 修正动作(由项目负责人完成) 完成日期:2007年9月14日 签名(公司/部门/科目): 验证(由评估者完成。如需要,使用下面的附加说明部分) 实施状态: 可接受:1-35, 38, 41-45/需要改进:36, 37, 39, 40 不可接受 : 签名:评估者 日期: 附加说明(如需要,由评估者完成) 36 更新的资质档案项目经理审查并批准 37 需改进已更新,然而需要工程师进一步检查是否已经录入所有的培训记录。 39&40 注UK SLCC已经执行后续独立审查,并标出一些附加改进 26仪器仪表标准化与计量 2009 . 4 Control Tech of Safety & Security 5 执行FSA的益处 执行FSA有诸多益处,主要有: * 针对功能安全

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论