功能安全技术讲座［编者按］ 本刊２００７年在“安全控制技术”栏目安排了六讲功能安全技术讲座，概要介绍了功能安全的基本概念、方法与技术，得到广大读者的广泛关注与积极回应。
２００８年，该讲座还将继续进行，针对读者关心、与功能安全相关的几个关键问题，进行更详细的技术介绍。
主讲人是全国工业过程测量和控制标准化技术委员会主任委员、机械工业仪器仪表综合技术经济研究所副所长冯晓升教授。
第十讲 功能安全的管理冯晓升（机械工业仪器仪表综合技术经济研究所，北京市 １０００５５）Feng Xiaosheng(Instrumentation Technology & Economy Institute, Beijing 100055)Chapter 10: Management for Functional safetyAbstract:Management is an indispensable means to achieve safety and is an important factor of impacting system failure.Functional safety management has its unique way of thinking and throughout the whole life cycle of safety at all stages.Key words: Management Functional Safety【摘 要】【关键词】管理作为影响系统失效的重要因素，是达到安全必不可少的手段。
功能安全管理贯穿于整体安全生命周期的所有阶段之中，有其独到的思想方法。
管理 功能安全１ 随机硬件失效和系统失效功能安全作为一种保障安全的思想方法，近几年已经被广泛了解和应用。
有大量的文章从不同的角度论述功能安全，但大多都是从技术方面来考虑问题。
其实，功能安全的最殊胜之处是将可以精确计算的硬件随机失效和难以精确定量分析的系统失效结合考虑并规划为一种半定量化的方法。
所以功能安全的管理作为影响系统失效的重要因素之一，是达到安全必不可少的手段。
为能正确理解这个问题，先将随机硬件失效和系统失效这两个概念介绍一下。
首先介绍随机硬件失效（ｒａｎｄｏｍ ｈａｒｄｗａｒｅｆａｉｌｕｒｅ），随机硬件失效是在硬件中，由于一种或几种机能退化可能产生的，按随机时间出现的失效。
既在各种部件中，存在以不同速率发生的许多机器退化，在这些部件工作了一段不同的时间之后，这些机能可使制造公差引起部件发生故障，从而使包含许多部件的设备将以可预见的速率，但在不可预见的时间（即随机时间）发生失效。
再介绍一下系统失效（Ｓｙｓｔｅｍａｔｉｃ ｆａｉｌｕｒｅ），系统失效是一种原因确定的失效，只有对设计或制造过程、操作规程、文档或其它相关因素进行修改后，才有可能排除这种失效。
对于系统失效来说，仅正确维护而不加修改，无法排除失效原因。
而且通过模拟失效原因可以导致系统失效。
在下列各条中以人为错误为原因引起的系统失效的例子有：——安全要求规范：——硬件的设计、制造、安装、操作；——软件的设计和实现等。
在功能安全标准中，安全相关系统的失效被分为随机硬件失效和系统失效。
随机失效和系统失效的主要区别是由随机硬件失效导致的系统失效率（或其它合适的量度）可用合理的精确度来预计，但系统失效生来就不能精确预计，因此系统失效引起的系统失效率则不能精确地用统计法量化。
从两个定义中不难看出，随机硬件失效的概念与可靠性一样，这类问题可以用提高可靠性、增加故障裕度或提高诊断覆盖率等办法来加以克服。
而系统失效则必须通过加强管理，改善过程才能克服。
２ 功能安全管理２．１ 功能安全管理框架功能安全的管理贯穿于整体安全生命周期的所有阶段之中，所以在整体安全生命周期的图示中虽然没有一个单独的阶段来表示，但标准中却用单独的一章来叙述。
因为在整体安全生命周期的每一个阶段以及每一阶段中的每个活动都必须用功能安全的管理来规范。
为了能够形象地说明这个问题，我们还是用大家都已十分熟悉的功能安全的整体安全生命周期图（见图１）来表示。
从图１中可以看出，功能安全的管理在整体安全生命周期中是无处不在的。
功能安全的管理简单地讲就是谁负责什么和通过什么活动来负责。
下面就专门介绍标准中对功能安全管理的基本考虑。
这些基本考虑只是一种思想方法，在具体实践中应根据情况加以细化。
２．２ 功能安全管理的目的功能安全管理的目的是确定对达到Ｅ／Ｅ／ＰＥ安全相关系统要求的功能安全所必需的，整体的安全生命周期、Ｅ／Ｅ／ＰＥＳ的安全生命周期和软件的安全生命周期所有阶段的管理和技术活动。
以及确定人员、部门和机构对整体的、Ｅ／Ｅ／ＰＥＳ的和软件的安全生命周期各阶段或各阶段中活动所负的责任。
要达到功能安全管理的目的首先要确定对整体安全生命周期的某一阶段或某几个阶段或某一阶段中的某项活动负全责的人员、机构或组织。
然后由这些人员、机构或组织在其所负责的范围内规定所有的管理和技术活动。
这个过程应是是分层次进行的。
２．３ 功能安全管理的内容这些管理和技术活动大体上应包括以下内容：１） 制定达到功能安全的整体战略。
同时，是否达到的评价方法要在事先确定好。
另外，为了确保从事有关安全工作的所有人员的素质，应规定在内部进行交流的方法；２） 对整体的安全生命周期、Ｅ／Ｅ／ＰＥＳ的安全生命周期或软件的安全生命周期各阶段，以及每个阶段中的每个具体活动负责执行的和负责复核的人员、部门或组织（包括有关的发证当局或安全管理机构）应有明确的识别办法；３） 要明确整体的安全生命周期、Ｅ／Ｅ／ＰＥＳ的安全生命周期或软件的安全生命周期被实施的阶段；４） 信息结构化和扩展信息文档化的方法；５） 应确定为了满足某一规定条款的要求，应该选择采取什么样的措施或技术；６） 应确定功能安全评估活动；７） 应有及时跟踪Ｅ／Ｅ／ＰＥ安全相关系统可能出现的问题并能够满意解决的规程，Ｅ／Ｅ／ＰＥ安全相关系统可能出现的问题可通过下列活动来加以发现：——危险和风险分析；——功能安全评估；——验证活动；——确认活动；——配置管理。
８） 应制定相应的规程，以保证与整体安全生命周期、Ｅ／Ｅ／ＰＥＳ安全生命周期或软件安全生命周期活动有关的相应图１ 功能安全的整体安全生命周期图责任部门能胜任其活动，尤其应规定下列几点：——对工作人员进行针对诊断和修复故障以及系统测试的培训；——对操作人员的培训；——对工作人员进行定期的再培训。
在功能安全的标准中，专门有一个附录Ｂ，给出了整体安全生命周期、Ｅ／Ｅ／ＰＥＳ安全生命周期或软件安全生命周期任何活动中，人的资格要求的指南９） 应制定这样的规程，即当发现危险事故（或产生危险的潜在事故）时，保证及时对其进行分析，并能提出使其重复发生的概率降到最低的建议；１０） 应制定对操作和维护进行分析的规程，尤其是：识别危及功能安全的系统故障的规程，包括用于检测重复性故障的日常维护所使用的规程；评估需求率和在操作和维护期间的失效率是否和系统设计期间的假设一致的规程；１１） 应制定定期功能安全审核的要求，包括：——功能安全审核频率；——审核责任部门和人员的独立性水平的考虑；——文档和后续活动；１２） 应制定如何启动对安全相关系统进行修改的规程；１３） 应制定对安全相关系统进行修改所需要的批准规程和规定谁是主管部门；１４） 应制定规程，以保持潜在危险和安全相关系统信息的准确性；１５）应制定在整体安全生命周期、Ｅ／Ｅ／ＰＥＳ安全生命周期和软件安全生命周期阶段中，Ｅ／Ｅ／ＰＥ安全相关系统的配置管理规程，尤其要对下列各项进行规定：——实现正式配置控制的阶段；——用于对一个项（硬件和软件）的全部要素进行唯一标识的规程；——防止未授权的项进入服务的规程；管理的细节可参见功能安全的标准中标准的附录Ｃ的 ［７］和［８］。
１６） 在适当场合的培训条款和应急服务信息。
以上所规定的所有活动应规定由谁来按规定实现，也就是对具体的事项规定具体的责任人。
并且能连续监视这些所规定的活动的开展。
以上所规定的所有活动在实施之前，应由有关机构正式复审并取得一致。
应正式得到相关机构的评审，并得到最终签署。
对于对整体安全生命周期、Ｅ／Ｅ／ＰＥＳ安全生命周期或软件安全生命周期的一个或多个阶段负全责的组织，产品或服务的供方应按其规定提供产品和服务，并应具有适当的质量管理系统。
最后，以上所规定的所有活动应告知所有对功能安全活动负有管理责任的各方，使其明白分配给他们的职责。
这一条是非常重要的，只有所有的责任人明白其职责并认真履行，才能保证风险在规定的目标以下。
我们经常会在大街上看到这样的标语“某某某某，人人有责。
”如果确实每个人都被告知了他应负的责任并认真履行，那么目标才可能实现。
如果说是人人有责，但每个人都并不明确他具体负有什么责任或并不认真履行，那么“某某某某，人人有责。
”就只是一句空洞的口号而已。
２．４ 功能安全管理软件要求除了以上所规定的所有常规的管理活动外，对于软件还有以下一些专门针对软件的应考虑的特殊要求。
１）功能安全计划应定义Ｅ／Ｅ／ＰＥ安全相关系统的安全完整性等级所要求的软件获取、开发、集成、确认和修改的战略。
该方法的理念是在编制计划时考虑Ｅ／Ｅ／ＰＥ安全相关系统部件所要求的各种安全完整性。
当软件执行不同安全完整性等级的安全功能时，所有的软件都被认为是属于最高安全完整性等级，除非在设计中表明不同安全完整性等级的安全功能之间具有充分的独立性。
软件安全完整性等级至少与所属安全功能的安全完整性等级一致。
但是如果软件组件用于与其它硬件组件结合，其结合的安全完整性等级至少与安全功能一致时，软件组件的安全完整性等级可低于软件组件所属安全功能的安全完整性等级。
２） 应制定软件配置管理规程ａ） 应在软件安全生命周期阶段中使用行政和技术控制，以管理软件变化和保证有关软件安全的规定要求始终能得到满足；ｂ） 应确保所有必需的操作已被执行以说明获得了所要求的软件安全完整性；ｃ） 应保持精确的和维护Ｅ／Ｅ／ＰＥ安全相关系统完整性所必需的所有配置项的唯一识别。
配置项至少包括：——安全分析和要求；——软件规范和设计文档；——软件源代码模块；——测试计划和结果；——将要被安装于Ｅ／Ｅ／ＰＥ安全相关系统的已存在的软件组件和软件包；——所有用于创建、测试或执行Ｅ／Ｅ／ＰＥ安全相关系统软件的工具和开发环境； （下转第２１页）测试，以提供证明他们能力和资质的信息。
要求提供的信息包括：１）作为一个权威认证机构的适当的运行证据，有＊ 国家授权的公认权威机构＊ 范围和认可日期＊ 可适用的标准细节和关于授权的证书２） 发展历程，包括对认证机构和审核人员的经验、能力和资质的描述，来提供的特定的第三方评估（和产品评估相对的功能安全管理）３） 国际认证企业机构及他们工作的国家４） 是否依赖于特定国家的代理机构，如果有则列出具体内容５） 互惠协议，例如＊ 谅解备忘录（ＭＯＲ）＊ 相认协定（ＭＲＡ）６） 评估人员的ＣＶ７） 评估过的机构列表，评估范围和企业内部的联系细节８） 对下述情况得描述：＊ 评估方法论＊ 评估过程＊ 给与被评估机构的指导性建议９） 用于进行第三方功能安全评估的典型工作计划（包括人工费用），包括一人－天的工作量１０） 预计的实施第三方评估计划现存的任何限制１１） 最近的公司审计说明１２） 组织性结构有必要建立一个公正并且独立的团队，代表该机构来评估在对一个国际第三方权威认证机构的遴选过程中产生的响应。