标准规范下载简介
GB／T 41295.2-2022 功能安全应用指南 第2部分：设计和实现.pdfICS. 25.040 CCS N 10
GB/T 41295.2—2022
Application guide of functional safetyPart 2:Design and realisatior
《高标准农田建设通则》国家市场监督管理总局 发布 国家标准化管理委员会
GB/T41295.22022
范围 规范性引用文件 术语和定义 缩略语 总则 安全生命周期 系统设计 系统架构设计 系统详细设计和实现 10软件设计和实现 11 系统集成 12 系统运行和维护规程 系统的确认 14生命周期各个阶段的验证 制造 ... 16 功能安全系统评估评测 参考文献
1系统实现过程的安全生命周期 图2系统设计要求规范与系统安全要求规范的关系 图3系统设计要求规范的分解.. 图4过程工业SIL目标分配示例 图5安全确认计划内容
GB/T41295.22022
本文件按照GB/T1.1一2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定 起草。 本文件是GB/T41295《功能安全应用指南》的第2部分。GB/T41295已经发布了以下部分： 第1部分：危害辨识和需求分析； 一第2部分：设计和实现； 一第3部分：测试验证； 一第4部分：管理和维护。 请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。 本文件由中国机械工业联合会提出。 本文件由全国工业过程测量和控制标准化技术委员会（SAC/TC124)归口。 本文件起草单位：上海辰竹仪表有限公司、机械工业仪器仪表综合技术经济研究所、国能智深控制 技术有限公司、浙江中控技术股份有限公司、北京康吉森技术有限公司、上海辰竹安全科技有限公司 本文件主要起草人：熊文泽、周婷、孟邹清、田雨聪、周有铮、裘坤、陈小全、黄之炯、左新、庞欣然 来晓、王璐、张亚彬、刘晓亮、徐神玲、刘瑶、帅冰
本文件按照GB/T1.1一2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定 起草。 本文件是GB/T41295《功能安全应用指南》的第2部分。GB/T41295已经发布了以下部分： 第1部分：危害辨识和需求分析； 一第2部分：设计和实现； 一第3部分：测试验证； 一第4部分：管理和维护。 请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。 本文件由中国机械工业联合会提出。 本文件由全国工业过程测量和控制标准化技术委员会（SAC/TC124）归口。 本文件起草单位：上海辰竹仪表有限公司、机械工业仪器仪表综合技术经济研究所、国能智深控制 技术有限公司、浙江中控技术股份有限公司、北京康吉森技术有限公司、上海辰竹安全科技有限公司 本文件主要起草人：熊文泽、周婷、孟邹清、田雨聪、周有铮、裘坤、陈小全、黄之炯、左新、庞欣然 来晓、王璐、张亚彬、刘晓亮、徐神玲、刘瑶、帅冰
GB/T41295.22022
自GB/T20438（所有部分）发布以来，电气/电子/可编程电子系统已经越来越多的应用于国内各 个领域的安全控制和安全防护，包括石油、化工、电力、轨道交通、汽车、电梯/扶梯等。近年来随着智能 制造的兴起，智能化设备（主要由电气/电子/可编程电子为技术基础）的安全问题逐渐成为一个新的研 究方向和焦点，进一步提升了对功能安全技术的需求。 GB/T20438（所有部分）给出了实现功能安全的基本框架和结构，作为等同转化的标准，与国内企 业的管理体系和设计思路未能完全切合，加之很多国内工程技术人员都是初次接触功能安全技术，对于 力能安全概念一时难以理解，这就造成虽然国际功能安全标准提出了非常好的安全理念和设计措施，但 支术人员难以清楚的理解和认识。GB/T20438（所有部分）发布10多年来，国内一些领先的科研院所 和企业已经基于标准要求开展了很多工作，并积累了一定的经验。因此，基于国内目前已有的功能安全 平估、功能安全设计、功能安全测试和功能安全管理实践形成本文件，以更好地指导功能安全相关系统 的设计、分析、评估和运行维护。 GB/T41295拟制定4个部分： 第1部分：危害辨识和需求分析。目的在于给出功能安全系统设计初期的危害辨识内容和需 求如何产生的方法； 第2部分：设计和实现。目的在于给出功能安全系统的软硬件设计和实现方法和实施指南； 第3部分：测试验证。目的在于给出功能安全系统在生命周期过程各个阶段的测试导则和测 试方法解读； 第4部分：管理和维护。目的在于给出功能安全系统管理和维护过程的导则
GB/T 41295.22022
功能安全应用指南 第2部分：设计和实现
功能安全应用指南 第2部分：设计和实现
本文件给出了设计和实现功能安全系统的指导措施，面向的对象包括安全传感器、安全逻辑控制 器、安全通信总线和安全执行器等。 本文件适用于功能安全系统研发团队（如制造商），就开发出符合相应安全完整性能力的安全产品 给出规范性指导：系统集成商 统的选型和评价参照执行
GB/T20438.4一2017界定的以及下列术语和定义适用于本文件。 功能安全系统functional safetysystem 执行安全相关功能的系统，具有功能安全相关的特性，满足特定的安全完整性等级（SIL）。 注：这里的系统是一个广义的概念，包括不同的层次，如安全部件、安全设备或安全控制系统等。在实际的工 程中，功能安全系统可能是一个变送器、继电器、安全可编程序控制器或安全仪表系统 「来源.GB/T41295.1—2022,3.6
GB/T20438.4一2017界定的以及下列术语和定义适用于本文件， 3.1 功能安全系统functionalsafetysystem 执行安全相关功能的系统，具有功能安全相关的特性，满足特定的安全完整性等级（SIL）。 注：这里的系统是一个广义的概念，包括不同的层次，如安全部件、安全设备或安全控制系统等。在实际的工业过 程中，功能安全系统可能是一个变送器、继电器、安全可编程序控制器或安全仪表系统。 来源GB/T41295.12022,3.67
GB/T41295.22022
功能安全系统研发团队teamforfunctionalsafetysystemresearchanddevelopment 执行功能安全系统设计研发的责任主体。 注：包括功能安全系统硬件开发人员、软件开发人员、验证测试人员、功能安全管理人员等。 3.3 功能安全系统制造团队functionalsafetysystemmanufactureteam 执行功能安全系统生产制造的责任主体，它可能包括功能安全系统制造过程的装配人员、测试 员、管理人员、加工人员等 注：为保证系统的安全功能正确制造，功能安全系统制造团队需要得到来自功能安全系统研发团队的有效协助 3.4 故障插入测试faultinjectiontest 人为地在功能安全系统中产生一种故障模式，验证系统在故障状态下的响应情况是否符合安全要 的种洲法
功能安全系统研发团队teamforfunctional safetysystemresearchanddevelopment 执行功能安全系统设计研发的责任主体。 注：包括功能安全系统硬件开发人员、软件开发人员、验证测试人员、功能安全管理人员等， 3.3 功能安全系统制造团队functionalsafetysystemmanufactureteam 执行功能安全系统生产制造的责任主体，它可能包括功能安全系统制造过程的装配人员、测试人 员、管理人员、加工人员等 注：为保证系统的安全功能正确制造，功能安全系统制造团队需要得到来自功能安全系统研发团队的有效协助。 3.4 故障插入测试faultinjectiontest 人为地在功能安全系统中产生一种故障模式，验证系统在故障状态下的响应情况是否符合安全要 的一种洲试注
人为地在功能安全系统中产生一种故障模式，验证系统在故障状态下的响应情况是否符 求的一种测试方法。
下列缩略语适用于本文件。 ASIC：专用集成电路（ApplicationSpecificIntegratedCircuit） CMMI：能力成熟度模型集成（CapabilityMaturityModelIntegration） CPLD：复杂可编程逻辑器件（ComplexProgrammableLogicDevice） DC：诊断覆盖率（DiagnosticCoverage) FMEA：失效模式与影响分析（Failuremodeandeffectanalysis） FMEDA：失效模式、影响与诊断分析（Failuremode，effectanddiagnosticanalysis） FPGA：现场可编程门阵列（FieldProgrammableGateArray） FTA：故障树分析(Faulttreeanalysis) HFT：硬件故障裕度(HardwareFaultTolerance) MooN:N取M通道架构(MoutofNchannelarchitecture) PFDavg：要求时危险失效平均概率（AverageProbabilityofdangerousFailureonDemand） PFH：危险失效平均频率（Averagefrequencyofdangerousfailure) SFF：安全失效分数（SafeFailureFraction) SIL：安全完整性等级（SafetyIntegrityLevel）
5.1功能安全系统的研发设计过程需要按照GB/T20438.2一2017和GB/T20438.3一2017等相关功 能安全基础标准的要求开展功能安全系统研发和验证工作。为保证预期的SIL目标和要求得以切实 实现，本文件给出了相关的应用指南。 注：某些领域有其特定领域的功能安全标准，这些领域的功能安全标准继承了GB/T20438.2一2017和GB/T20438.3 2017的整体架构和核心理念，因此在符合这些领域功能安全要求时，也可参考本文件的相关内容 5.2功能安全系统还宜满足其产品标准中关于基本安全（如电气安全）、环境适应性以及可靠性/稳定 性的特定要求，这些要求是实现相应安全完整性的前提。 5.3功能安全系统的生产制造过程需要考虑第15章或相关领域功能安全标准中的规定。
GB/T41295.22022
6.1.1功能安全系统研发团队需要在安全研发的初期建立功能安全管理体系和定义安全生命周期 价段。 6.1.2功能安全管理体系和安全生命周期的建立需要结合功能安全标准要求以及研发团队的已有 经验。
6.2.1功能安全管理体系需要考虑GB/T20438.1一2017中第6章的要求，功能安全研发部门可以参 考公司已有的质量/安全管理体系来建立功能安全管理体系。 注：GB/T19001一2016或CMMI等体系的构建和实施是实现功能安全管理的有力保障。 6.2.2功能安全管理体系需要包含系统或软件变更的需求，需要考虑GB/T20438.2一2017中7.8和 GB/T20438.3一2017中7.8的要求。当变更发生后，宜按照制定的变更规程执行影响分析，留存变更 记录。 6.2.3典型的安全生命周期过程需要考虑GB/T20438.2一2017和GB/T20438.3一2017中第7章的 要求，功能安全系统研发团队按照该章的要求建立满足自已研发特性的安全生命周期。 6.2.4功能安全系统实现过程的安全生命周期需求包括：系统设计要求规范（包括软件安全要求规 范）、系统的架构设计、系统的详细设计和实现、软件设计和实现、系统集成（包括子系统软硬件集成和子 系统间集成）、系统运行和维护规程（包括用户手册、安全手册等）、系统的安全确认（包括软件确认）、系 统的制造。功能安全系统的安全生命周期见图1
6.2.5对系统的修改和验证的要求贯穿于以上生命周期的所有阶段。
图1系统实现过程的安全生命周期
GB/T41295.22022
7.1.1功能安全系统设计要求规范的基本要求需要考虑GB/T20438.2一2017中7.2和B.1的要求。 7.1.2系统设计要求规范中需要包括系统的所有设计要求，包括安全相关要求和非安全相关要求。宜 等安全相关要求和非安全相关要求明确区分开来，对于非安全相关要求可以不必接照生命周期后续活 动执行。 7.1.3对与某些与应用联系非常紧密的产品（例如，轨道交通产品，汽车电子产品），安全要求和非安全 要求的界定需要根据具体的应用加以分析，并将分析过程文档化。 7.1.4宜对所有的安全要求保持追溯，典型的追溯方法包括：采用专业的要求管理工具，采用特定的编 号系统等。 7.1.5在系统设计要求规范和软件安全要求规范编制完成后，需要按照GB/T20438.2一2017中图2 和GB/T20438.3一2017中图6的V模型，在每一阶段开展对其的验证，验证形式包括内部测试、外部 则试、会议审查、专家评定或建模分析等。验证完成后形成正式的验证记录， 7.1.6需要按照GB/T20438.2一2017中7.3编制系统安全确认计划
7.2.1系统设计要求与系统安全要求的关系，女
统设计要求与系统安全要求的关系，如图2所示
图2系统设计要求规范与系统安全要求规范的关系
2一般情况下，系统设计要求规范可以包括功能级的要求和单独的硬件要求，对于复杂的系统 单独编制硬件安全要求规范。 3系统设计要求规范宜进行如图3的分解
GB/T41295.22022
图3系统设计要求规范的分解
图4过程工业SIL目标分配示例
7.2.7其他部件也是执行整个安全回路的必要组成部分，如安全栅、安全继电器等；其他部件 安全功能执行没有直接相关的部分
GB/T41295.22022
7.2.8安全确认计划宜包含的内容见图5
图5安全确认计划内容
8.1.1需要基于系统设计要求规范开展系统（硬件）架构设计。 8.1.2对于相对简单的功能安全系统，系统架构设计可以合并到系统设计要求规范阶段实施，但单独 的软件架构设计是必要的。 3.1.3对于相对复杂的功能安全系统，宜建立单独的系统架构设计阶段。 8.1.4架构设计需要考虑GB/T20438.2一2017中7.4的适用要求。 3.1.5需要考虑对架构设计开展验证， 8.1.6需要考虑基于架构设计内容编制集成测试计划
8.2架构设计应用考虑
架构设计在保障功能安全上面需要考虑如下方面： 保证系统足够的健壮性； 保证不同模块之间适当的独立性，避免复杂的耦合关系和共因失效； 保证非安全相关模块不会对安全相关模块造成负面影响
GB/T41295.22022
8.2.2需要对架构设计的静态特性进行规范性描述（仅 ，对组成系统采构的母模块科 模块间接口进行描述。 3.2.3架构设计宜避免对每个模块内部的实现细节进行描述，这些细节是后续详细设计的内容。 8.2.4可以考虑采用多通道的MooN表决结构来实现高安全或高可用设计。可以在不同层次上实现 多通道表决，在设备层、模块层、板卡层，甚至芯片层， 8.2.5需要明确区分MooN表决结构和备用结构之间的差异，一般情况下备用结构是用于提高可用* 而非安全*。 8.2.6需要在完成架构设计验证之后，制定集成测试计划，其中包括对所有架构特*和接口特*的测 试策略
9.1.1功能安全系统设计和研发的基本要求需要考虑GB/T20438.2—2017中7.4、附录A 要求。
9.2.1随机硬件失效的要求
GB/T41295.22022
气特*的降额因子不宜高于67%，对于温度的降额宜不小于10℃ 9.2.1.10需要形成文**的分析材料，以证明降额设计的合理*，宜开展测试对降额的实现情况进行 验证。
9.2.2硬件失效分析要求
常用的分析方法包括FMEDA、FTA等 9.2.2.2基于元器件失效后对模块的影响以及是否能够被诊断到，失效分析宜将每种失效分类为以下 几种类别之一： 可诊断到的安全失效（入SD）； 不可诊断到的安全失效（入sU）； 可诊断到的危险失效（入DD）； 不可诊断到的危险失效（入DU）； 无影响失效， 注：对于架构设计阶段已经界定为安全无关的模块，可以不对其元器件开展详细的失效分析木料表面施涂丙烯酸清漆磨退高级涂料施工工艺标准（931-1996），这些部件的失效在 GB/T20438（所有部分）中被定义为无关失效。 9.2.2.3对于复杂的子系统或元器件，如果其失效后安全或危险难以判定，可以将其按照50%安全， 50%危险的方式进行划分， 注：在一个有效的分析过程中，不宜简单的将大部分的元器件按照50%的方式划分，这会导致最终的PFDavg PFH,SFF等参数非常差，甚至连SIL1都达不到，这样的分析是没有意义的。 9.2.2.4需要注意区分安全失效和无影响失效，不能将无影响失效纳入安全失效之中。 9.2.2.5基于硬件失效分析的结论需要对已有安全设计进行复审，确保所有关键故障都得到有效控制 或避免。 9.2.2.6需要仔细判断每个诊断功能的有效*，无效的诊断不能将对应的失效归类为可诊断的，无效的 诊断包括但不限于： 诊断测试间隔过长，不满足过程安全时间的要求； 如果采用多通道设计，单纯的通道间表决不能作为单个通道内器件失效的诊断措施；
9.2.3诊断覆盖率的判定
需要仔细判断每个诊断功能的覆盖率，一般按照如下考虑进行判定 对于简单元器件，如果诊断测试能够诊断到它的某种失效模式，则该器件这种失效模式的诊断 覆盖率为100%，否则为0%，简单器件例子：电阻、电容、三极管、二极管、光耦等 对于复杂的器件，原则上基于GB/T20438.2一2017中A.1～A.14的要求。如果有更高诊断 覆盖率的申明或者采用了GB/T20438.2一2017中附录A没有规定的技术，采用测试的方法 证明所实现诊断覆盖率的真实*。复杂元器件的例子：中央处理器（CPU）、模数转换（ADC） 芯片、存储单元等。 对同一器件或模块，可使用两种或更多种诊断方法来诊断相同的失效模式，这种方式可以实现 比GB/T20438.2一2017中附录A规定的更高诊断覆盖率。但这些不同方法一定是独立的， 且不具有共因失效的可能
诊断功能及诊断覆盖率（
GB/T41295.22022
系统遵循了单一失效原则； PFDaVg/PFH满足了目标失效量的要求； SFF满足了架构约束的要求。 注：足够的诊断功能可以更加利于以上要求的实现，但并不是单单依靠诊断功能博物馆新馆暖通安装专业工程施工组织设计方案，例如，失效率高低和检验测试间 隔长短对于PFDavg/PFH是否满足要求也有重大影响。当这些要求无法满足时，可以考虑是否通过提高诊断 能力进行改善
PFDaVg/PFH满足了目标失效量的要求； SFF满足了架构约束的要求。 注：足够的诊断功能可以更加利于以上要求的实现，但并不是单单依靠诊断功能，例如，失效率高低和检验测试间 隔长短对于PFDavg/PFH是否满足要求也有重大影响。当这些要求无法满足时，可以考虑是否通过提高诊断 能力进行改善。 9.2.4.2诊断功能的设计满足检测到故障后系统的行为要求。 9.2.4.3需要但不限于在如下两个阶段执行诊断： 一在系统初始化时，诊断重点是所有的硬件，内部或外部数据通路等； 一正常运行时周期中执行诊断功能，诊断重点包括硬件、软件、软错误、数据通路等。 9.2.4.4宜基于系统的运行周期和所有诊断功能实现的时间，确定所有诊断的间隔时间，即诊断测试间 满（TD）。 9.2.4.5诊断测试间隔要足够小，以满足GB/T20438.2一2017中7.4.5.3和7.4.5.4。 9.2.4.6某些诊断功能为避免频繁的误动作，可能会采取多次判断后诊断决策的机制，需要考虑到这种 多次判断和重试可能会导致进人到某种死循环或无法实现所规定的诊断能力
在系统初始化时，诊断重点是所有的硬件，内部或外部数据通路等； 一正常运行时周期中执行诊断功能，诊断重点包括硬件、软件、软错误、数据通路等， 9.2.4.4宜基于系统的运行周期和所有诊断功能实现的时间，确定所有诊断的间隔时间，即诊断测试间 隔（TD）。 .2.4.5诊断测试间隔要足够小，以满足GB/T20438.2一2017中7.4.5.3和7.4.5.4。 .2.4.6某些诊断功能为避免频繁的误动作，可能会采取多次判断后诊断决策的机制，需要考虑到这种 多次判断和重试可能会导致进人到某种死循环或无法实现所规定的诊断能力