ChinaAutoRegs｜GB/T 34590.10-2022英文版翻译English 道路车辆功能安全第10部分：指南（英语版）
Road Vehicles—Functional Safety—Part 10: Guideline
CONTENTS
Foreword
Introduction
1 Scope
2 Normative References
3 Terms and Definitions
4 Key concepts of GB/T 34590
5 Selected topics regarding safety management
6 Concept phase and system development
7 Safety process requirement structure — Flow and sequence of the safety requirements
8 Concerning hardware development
9 Safety Element out of Context
10 An example of proven in use argument
11 Concerning ASIL decomposition
12 Guidance for system development with safety-related availability requirements
13 Analysis on “Confidence in the use of software tools”
14 Guidance on safety-related special characteristics
Annex A (Informative) Fault tree construction and applications
Bibliography
1 范围
GB/T 34590的本部分提供了GB/T 34590的概览，也给出了额外的解释，目的是增强对本文件其它部 分的理解。本文件只具有资料性特性，描述了GB/T 34590的一般概念以便于理解。该解释将一般概念扩 展到特定的内容。
本文件适用于安装在除轻便摩托车外的量产道路车辆上的包含一个或多个电气/电子系统的与安全 相关的系统。
本文件不适用于特殊用途车辆上特定的电气/电子系统，例如，为残疾驾驶者设计的车辆。 注：其他专用的安全标准可作为本文件的补充，反之亦然。 已经完成生产发布的系统及其组件或在本文件发布日期前正在开发的系统及其组件不适用于本文
件。对于在本文件发布前完成生产发布的系统及其组件进行变更时，本文件基于这些变更对安全生命周 期的活动进行剪裁。未按照本文件开发的系统与按照本文件开发的系统进行集成时，需要按照本文件进 行安全生命周期的剪裁。
本文件针对由安全相关的电气/电子系统的功能异常表现而引起的可能的危害，包括这些系统相互 作用而引起的可能的危害。本文件不针对与触电、火灾、烟雾、热、辐射、毒性、易燃性、反应性、腐 蚀性、能量释放等相关的危害和类似的危害，除非危害是直接由安全相关的电气/电子系统的功能异常 表现表现而引起的。
本文件提出了安全相关的电气/电子系统进行功能安全开发的框架，该框架旨在将功能安全活动整 合到企业特定的开发框架中。本文件规定了为实现产品功能安全的技术开发要求，也规定了组织应具备 相应功能安全能力的开发流程要求。
如果本文件与GB/T 34590其它部分存在不一致时，以GB/T 34590其它部分中定义的要求、建议和信 息为准。
2 规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件， 仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本 文件。
GB/T 34590.1 道路车辆 功能安全 第1部分：术语（ISO 26262-1:2018，MOD）
3 术语、定义和缩略语
GB/T 34590.1界定的术语、定义和缩略语适用于本文件。
4 GB/T 34590 中的关键概念
4.1 针对汽车系统的功能安全（与 GB/T 20438 的关系）
GB/T 20438《电气/电子/可编程电子安全相关系统的功能安全》是关于电气、电子、可编程电子安 全相关系统的功能安全通用标准和基础安全标准。这意味着，各工业领域将基于GB/T 20438的要求建立 自身的功能安全标准。
在汽车行业, 如果直接应用GB/T 20438标准会存在许多问题。其中的一些问题相对应于GB/T 34590 系列标准的差异描述如下。
GB/T 20438基于“受控设备”模型，例如具有如下关联控制系统的工业装置：
a) 使用危害分析识别出与受控设备（包括设备控制系统)关联的危害，并对此应用可降低风险的 措施。这可通过电气/电子/可编程电子系统、其它技术的安全相关系统（例如：安全阀）、 或外部措施（例如：对装置的物理围堵）来实现。GB/T 34590 系列标准基于严重度、暴露概 率和可控性，为危害分级提供了规范化的汽车领域的方案。
b) 电气/电子/可编程电子系统可通过完成如下设计的安全功能来降低所分配的风险。这些安全 功能可以是独立的保护系统的一部分、也可以被纳入到装置控制中。在汽车系统中，未必都 能做出这种区分。车辆的安全依赖于控制系统自身的表现。
GB/T 34590使用了安全目标和安全概念的如下观念：
——通过危害分析和风险评估识别出需要防止、减轻或控制的危害和危害事件；
——每个被评为 ASIL A, B C 或 D 的危害事件与至少一个安全目标关联；
——将汽车安全完整性等级（ASIL）与每个安全目标关联；
——功能安全概念表述了实现安全目标的功能；
——技术安全概念表述了如何在系统层面通过硬件和软件实现安全功能；及
——软件安全要求和硬件安全要求表述了特定的安全要求，这些要求将作为软硬件设计的一部分 而被实施。
示例：安全气囊系统：
——其中一个危害是非预期气囊起爆；
——相关的安全目标是气囊只在发生需要气囊起爆的碰撞时起爆；
——功能安全概念可定义冗余的功能来探测车辆是否发生碰撞；
——技术安全概念可定义两个具有不同轴向的独立加速度传感器和两个独立点火回路的实施方案，如果 两路均闭合则起爆点火管。
GB/T 20438针对的是单一的或小批量的系统。系统经过制造和测试后安装到装置上，然后执行安全 确认。对于大批量销售的系统，如道路车辆，安全确认在量产之前执行。因此GB/T 34590中生命周期活 动的次序有所不同。对此，GB/T 34590.7提出了对生产的要求。而在GB/T 20438中并未覆盖此部 分内容。
GB/T 20438未对管理跨多个组织和供应链的开发提出特定要求。因为汽车系统是由整车厂自身、由 整车厂的一个或多个供应商或由整车厂与供应商合作生产的，GB/T 34590包含了明确地解决这个问题的 要求，包括开发接口协议(DIA)（见GB/T 34590.8，第5章)。
GB/T 20438不包含对危害分级的规范化要求。GB/T 34590则包含了汽车领域危害分级的方案。此方 案认为汽车系统的危害并不一定会导致事故。其结果取决于涉险人员是否实际暴露在危害发生的场景下， 及相关人员能否采取措施以控制危害的结果。图2给出了此概念的示例，将其应用到了一个对运动中车 辆可控性有影响的失效上。
注：此概念仅为了阐述失效的发生和事故之间没有必然的直接关联。尽管此过程中评估的参数与图中状态过渡的可 能性相关，但它不是危害分析和风险评估过程的展示。
为符合汽车工业的当前技术水平，对硬件开发（GB/T 34590.5）和软件开发（GB/T 34590.6） 要求进行了调整。对于GB/T 34590中列出的方法给出了特定的目标；为实现这些目标，可应用给出的方 法，或应用替代方法，但需提供理由证明替代方法也能实现目标。
为GB/T 34590中的安全要求分配汽车安全完整性等级（ASIL）而不是安全完整性等级（SIL），其 主要原因是GB/T 20438中的SIL表述为概率术语（见GB/T 20438.1-2006，表3）。GB/T 20438确认，对 于系统安全完整性常常需要定性判断，而对于硬件安全完整性需要量化技术。GB/T 34590中ASIL主要关 注在系统、硬件和软件中实现系统安全的要求，但也存在关于符合ASIL随机硬件失效要求的概率目标。
4.2 相关项、系统、要素、组件、硬件元器件和软件单元
GB/T 34590.1中定义了相关项、系统、要素、组件、硬件元器件和软件单元。图3展示了系统、 要素、组件、硬件元器件和软件单元的关系。图4举例展示了相关项的分解（构成关系）。可分解的要 素可被标注为系统或组件。满足系统标准的可分解要素可被标注为系统。组件是非系统层面的、逻辑上 和技术上独立的要素。通常，术语“组件”用于仅由元器件和单元组成的要素，但也能用于由更低层面 的特定技术领域（例如：电子电气技术，见图4）要素组成的要素。硬件元器件还可以进一步按层次由 硬件子元器件和硬件基本子元器件组成。
4.3 故障、错误和失效之间的关系
4.3.1 故障到错误并从错误到失效的发展过程
在GB/T 34590.1中定义了术语：故障、错误和失效。图5从三个不同类型的原因（系统性软件 问题、随机硬件问题和系统性硬件问题）描述了故障到错误并从错误到失效的发展过程。系统故障（见 GB/T 34590.1, 3.165）起因于设计和规范的问题；软件故障和部分硬件故障是系统性的。在组件 层面，每个不同类型的故障会导致不同的失效。然而，组件层面的失效是相关项层面的故障。注意，在 此示例中，整车层面不同原因导致的故障可引起相同的失效。如果额外的环境因素使失效叠加了事故场 景，相关项层面的部分失效将会是危害（见GB/T 34590.1, 3.75）。
4.4 FTTI 和紧急运行容错时间间隔
4.4.1 介绍
GB/T 34590-XXX, 6.4.4.3在注释中指出，FTTI可作为安全目标的一部分被包含在其中。此外，GB/T 34590.4 6.4.2.2规定了，在定义每种安全机制的故障处理时间间隔时，应考虑FTTI和紧急运行容 错时间间隔。
注：故障处理时间间隔是给定的安全机制的一种特征。故障容错时间间隔（FTTI）相关项的一种特征。
作为概念阶段确定安全目标和功能安全要求流程的一部分，FTTI是基于车辆功能的整车级定义。在 产品开发期间需考虑该时间跨度，确定最大故障处理时间间隔，以避免危害事件（例如：在GB/T 34590.1 图5中所描述的故障探测时间间隔和故障反应时间间隔的总和）。FTTI是设计安全机制响 应时间的必要值。在FTTI内，故障由安全机构控制，可以防止危害事件发生。当故障探测时间间隔和故 障反应时间间隔之和比FTTI短时，它可以实现。
当无法在FTTI内达到安全状态时，需定义紧急运行（GB/T 34590.4 6.4.2.2)。紧急运行是一 种被定义为警告和降级策略的一部分的运行模式。在FTTI结束之前启动紧急运行，并在紧急运行容错时 间间隔结束之前，维持直到安全状态为止。为满足安全目标，应在紧急运行容错时间间隔结束之前达到 安全状态。
4.4.2 时序模型-控制系统示例
4.4.2.1 控制系统说明
本条将故障探测时间间隔（FDTI)、故障容错时间间隔（FTTI)、故障响应时间间隔（FRTI)、紧急 运行容错时间间隔（EOTTI)和诊断测试时间间隔（DTTI)的概念应用于阀门控制系统示例。该系统由阀 门、位置传感器、控制器和电机组成。该系统的功能是使用电机将阀门控制到所需的位置。
如果阀门开度超过预期百分比，则可能发生意外流量导致危险事件。作为一种故障响应，电机由一 个带有机械弹簧的独立电路断电，机械弹簧将阀门拉到预设的固定开度位置。这个固定开度位置限制了 流量，从而使相关项处于安全状态。
4.4.2.2 时序模型在示例控制系统中的应用
GB/T 34590.10—XXXX
在此示例中考虑的特定失效模式是电机故障，它启动阀门达到其最大开度位置。这种情况可能是电 机因电源短路或其他电机控制问题造成的。考虑了四种场景。
——场景 1：系统没有任何安全机制避免违反安全目标。 电机中出现短路导致阀门达到其最大位置。因为没有安全机制，一旦超过 FTTI,就会发生危害 事件。
——场景 2：系统具备已实施的无紧急运行的安全机制，且 FTTI 内达到了安全状态。 电机中出现短路导致阀门达到其最大位置。已实施的安全机制使阀门电机断电，且机械弹簧 在 FTTI 内使阀门返回到低流量位置。安全机制（弹簧）设计为无期限运行，安全状态可以是 无限的。
——场景 3：系统具备已实施的可以在 FTTI 内避免危害事件的安全机制，但需要紧急运行来过渡 为安全状态。通过限制车辆的运行状态，可以在紧急运行容错时间间隔内达到安全状态。 电机中出现短路导致阀门达到其最大位置。已实施的安全机制使阀门电机断电，且机械弹簧 在 FTTI 内使阀门返回到低流量位置。安全机构（弹簧）仅设计为在有限时间内运行，即 EOTTI。 在 EOTTI 到期之前，车辆运行状态应受到限制，使得来自阀门的流量不会导致危害事件。
——场景 4：系统具备已实施的可以在 FTTI 内避免危害事件的安全机制，但需要紧急运行来过渡 为安全状态。然而，其过渡时间比 EOTTI 长。因此，累积的风险变得无法接受，超出了功能 安全概念中指定的目标。 电机中出现短路导致阀门达到最大开度位置。已实施的安全机制使阀门电动机断电，并且机 械弹簧在 FTTI 内将阀门返回到低流量位置。安全机制（弹簧）只设计为在有限的时间内运行， 即 EOTTI。在这种场景下，车辆运行不受限制，相关项处于比 EOTTI 终止时间长的紧急运行状 态，从而导致违背安全目标的不合理风险。
图6展示了与这四种场景相关的时序模型。图6基于GB/T 34590.1图4和GB/T 34590.1图5。
图 6 包括下列描述的 7 个时间戳： t1:在故障发生之前诊断测试的时间。 t2:故障发生，故障未被探测。
t3:故障探测（例如，由于错误计数器达到其阈值，见 GB/T 34590.1, 3.55 FDTI 示例），故障响 应时间间隔开始。
t4:完成到安全状态的过渡（场景 2），紧急运行开始（场景 3 和 4）。
t5:紧急运行结束（场景 3）。 t6:紧急运行的时间限度。 t7:危害事件发生。
4.4.2.3 警告和降级策略
当阀门处于默认位置时，可能产生整车层级的影响。功能安全概念可能还包括在此状态下警告驾驶 员的要求。这是警告和降级策略的一部分，由图6上的“驾驶员警告提示灯打开”箭头指示，该箭头可能 在t3之后的指定时间内发生。
5 关于安全管理的精选话题
5.1 工作成果
本条描述术语“工作成果”。
工作成果是满足GB/T 34590系列标准的相应要求的结果（见GB/T 34590.1）。因此，工作成 果可提供符合这些安全要求的证据。
示例：需求规范是可通过需求数据库或文本文件来记录的一种工作成果。可执行模型是能通过可执行建模语言文件 表示的一种工作成果（例如，通过使用软件工具达到仿真的目的）。
工作成果的文档（见GB/T 34590.8第10章）作为已执行的安全活动、安全要求或相关信息的 记录，不局限于任何形式或媒介。
示例：工作成果的文档可通过电子或纸质文件表示，通过单一或系列文档表示。它可以与其它工作成果的文档合并， 或与非功能安全直属文档合并。
为避免信息重复，可在文档内或文档间使用交叉引用。
5.2 认可措施
5.2.1 总则
GB/T 34590中定义的工作成果，或作为认可措施的一部分，或作为验证活动的一部分，在后续活动 中得到评估。本条描述了验证和认可措施间的差异。
验证活动是GB/T 34590中，为证明工作成果是合适的且遵守相应要求的，提供证据的主要措施。工 作成果的验证可包括：
——参照更高层面的安全要求，关于完整性及正确性，对导出的安全要求的规范或实施的验证； 或
——测试案例的执行与测试结果的检查，通过检测相关项或其要素，来提供满足已定义的安全要 求的证据。
GB/T 34590.3、GB/T 34590.4、GB/T 34590.5和GB/T 34590.6中对验证活动
进行了定义。此外, GB/T 34590.8第9章定义了有关GB/T 34590系列标准的验证活动的一般要求， GB/T 34590.8第6章定义了对安全要求进行验证的进一步细节。
对工作成果的验证，可用如下方法进行：
——评审；
——仿真；
——分析； 或
——测试。
GB/T 34590.2中定义了认可措施。执行认可措施用以评估相关项功能安全的实现。
示例：如果在系统架构设计阶段应用 ASIL 分解，则：
——根据技术安全概念（见 GB/T 34590.4,6.4.9）对生成的系统架构设计进行验证；及
——按照 GB/T 34590.9 第 5 章（关于 ASIL 剪裁的要求分解）对正确实施 ASIL 分解的确认，可作 为功能安全评估的一部分，包括：对已经开展的相关失效分析的确认和对声明执行相应冗余安全要 求的要素间具备充分独立性的论证。
5.2.2 功能安全评估
如果相关项安全目标的最高ASIL等级是ASIL C或D，则开展功能安全评估以评价相关项是否实现功 能安全。在GB/T 34590.2中，描述了功能安全评估的某些方面，以及认可措施的其他方面。
功能安全评估的范围在GB/T 34590.2，第6章中定义。 对实施功能安全评估的情况，功能安全审核以及认可评审的结果是功能安全评估的输入。负责评估
的人员可根据他/她的自由裁量权进行评估，包括如何使用功能安全审核与认可评审的结果。
示例 1：如果功能安全审核的结果令人满意，负责功能安全评估的人员可决定信赖审核结果，而不对功能安全所要 求的过程的实施做进一步判断。
示例 2：基于某一特定工作成果的认可评审报告，负责评估的人员可决定实施，或要求对工作成果的某些方面更深 入的评审，或可检查是否认可评审充分地考虑了工作成果与相关工作成果之间的相互影响。
注1：负责功能安全评估的人员实施某一特定认可评审是可能的，即认可评审不一定由与负责评估的人员不同的人 员实施。
功能安全评估可被重复或更新。
示例 3：因变更管理流程识别出相关项或其要素的变更对相关项的功能安全存在影响（见 GB/T 34590.8，第 8 章），而对功能安全评估进行更新。
示例 4：对相关项功能安全建议“有条件接受”或“拒绝”的功能安全评估报告，触发功能安全再评估。在此情况 下，重复评估包含对上一次功能安全评估所做建议的跟进，如果适用，还包括对已实施的纠错行动的评价。
如果相关项安全目标的最高ASIL等级是ASIL A或B，功能安全评估可被省略或以不严格的方式执行。 然而，即使不执行功能安全评估，仍需执行其它认可措施（见GB/T 34590.2，表1）。
在分布式开发的情况下，功能安全评估的范围包括由整车厂和相关项供应链中的供应商生成的工作 成果、实施的流程及安全措施（见GB/T 34590.2和GB/T 34590.8，第5章）。
功能安全评估的目的是评价相关项功能安全的实现，这只能在相关项层面进行。因此，（开发相关 项要素的）供应商所作的功能安全评估具有局限性，从本质上它是后续（客户层面）功能安全评估活动 的输入。作为相关项开发中的最终客户，整车厂指派人员开展全面的功能安全评估，以判断相关项功能 安全的实现。此判断包括对相关项的功能安全提供“接受”、“有条件接受”和“拒绝”的建议。
注2：对于由一级供应商负责包括整车集成的相关项开发的情况，该供应商承担整车厂的上述角色。
实际方法上，分布式开发中的功能安全评估可就此分解为：
——有限范围的功能安全评估，涉及供应链中的供应商。适用的 ASIL 等级是供应商开发的相关项 各要素所继承的（相关项各安全目标的）最高 ASIL 等级(见 GB/T 34590.8，5.4.5)；及
——最终的功能安全评估，包括对集成的相关项实现功能安全的判断，例如由整车厂开展的评估。 适用的 ASIL 等级是安全要求中最高的 ASIL 等级(见 GB/T 34590.2)。
示例 5：整车厂开发一个具有 ASIL D 安全目标（SG1）和 ASIL B 安全目标（SG2）的相关项，并将对其开展功能安 全评估。存在如下可能情况，某二级供应商或三级供应商只开发了相关项的 ASIL B 要素，即仅继承 SG2 的 ASIL 等级的 要素（然而，如果要素共存的标准适用，参考 GB/T 34590.9，第 6 章）。关于具有独立 IO 的此要素开发，GB/T 34590， 表 1，提供了实施功能安全评估的建议。
与客户和供应商接口有关的功能安全评估的范围、评估的流程（例如：需由供应商提供的工作成果， 需由客户评审的工作成果）和评估的执行，在相应开发接口协议中进行了定义（见GB/T 34590.8， 第5章）。
示例 6：整车厂（客户）与一级供应商之间的开发接口协议（DIA）。一级供应商与二级供应商之间的开发接口协议
（DIA）。
在分布式开发的情况下，功能安全评估的可能开展方式是整车厂和供应链中的供应商各自处理所负 责的评估活动的如下方面：
——供应商对所开发要素中实施的安全措施进行评审，包括措施对满足相应安全目标或安全要求
（由客户提供或由供应商开发）的适当性和有效性，并评估安全措施的实施过程及适用的工 作成果。供应商也评估所开发要素对相关项功能安全的潜在影响，例如：对实施的可带来新 危害的安全措施的识别；及
——整车厂对集成后的相关项的功能安全进行评估。评估的一部分可基于由一个及以上供应商提 供的工作成果或信息，包括功能安全评估报告。
注3：客户可对供应商实施的安全措施及完成的工作成果进行评估。客户也可在供应商处对供应商实施的过程进行 评估（见GB/T 34590.8，5.4.3.1）。
5.3 安全档案的理解
5.3.1 安全档案的解释
安全档案的目的是提供一个由证据支持的、清晰的、全面的和正当的论据，以证明当运行在预期的 环境中时，相关项不存在不合理的风险。
此处提供的指南聚焦于GB/T 34590的范畴。 安全档案有三个主要素：
——安全目标和相关安全要求（相关项或要素的安全目的）；
——安全论证；及
——GB/T 34590 系列标准的工作成果（即，证据）。 图7描述了GB/T 34590系列标准上下文中这三个要素间的关系。
图 7 安全档案（见参考文献[2]）的关键要素
安全论证表达了证据和目标之间的关系。可能展示了许多页的支持证据却没有清晰的解释此证据如 何联系到安全目标。论证和证据都是安全档案的决定性要素。没有支持证据的论证是没有事实根据的， 因此是不足以令人相信的。没有论证的证据是不清楚的，以致缺乏安全目标如何得到满足的清晰解释。 通过开发和展示安全档案报告，表达安全档案。安全档案报告的任务是汇总安全论证，并对记录安全支 持证据的报告进行引用（例如：测试报告）。
在其它行业中使用的安全论证，经常是通过叙述性文本的安全案例报告表达的。叙述性文本可描述 安全目标是如何被解释、分配和分解的，最终引用证据证明符合较低层面的安全声明。或者，作为一种
辅助，图形化论证符号（如：“声明-论证-证据”和目标结构表示法[2]）可被用以形象化的和明确的 展示安全论证的独立要素（要求、声明、证据和背景），同时展示这些要素间存在的关系（即，特定声 明如何支持独立要求，证据和为论证定义的假设背景如何支持声明）。
通过直接诉诸实施的相关项的特征（例如：定时看门狗的行为）来证明安全的安全论证通常被称为 产品论证。通过诉诸开发和评估过程的特征（例如：采用的设计符号）来证明安全的安全论证通常被称 为过程论证。
可使用两种类型的论证，以达到对相关项安全的完整论证，这里，过程论证可被看成是为产品论证 中用到的证据提供可信度。
5.3.2 安全档案开发生命周期
安全档案的开发可被视为与安全生命周期内其余开发阶段集成的增量活动。 注：安全计划可包含安全档案增量步骤的计划和安全档案初始版本的计划。 这种方法允许在产品开发的给定节点生成安全档案的中间版本。例如：安全档案的初始版本可在技
术安全要求验证后生成；安全档案的中间版本可在系统设计验证后生成；及最终版本可在功能安全评估 的最终报告前生成。
安全档案需符合GB/T 34590.2,6.4.9中给定的认可评审。 如果相关项被修改，需评估对安全档案的影响，如果必要，需根据修改对安全档案进行更新。
6 概念阶段和系统开发
6.1 总则
本章通过使用简单的示例，为概念阶段提供了危害分析和风险评估的原理概览。
6.2 危害分析和风险评估示例
6.2.1 总则
考虑以控制车载嵌入式能量存储装置的相关项为示例。关于此示例的用途，只有在车辆行驶速度大 于等于15km/h时才试图释放储存的能量。如果车速低于15km/h，储存能量的释放会导致过热进而引发装 置爆炸。
6.2.2 HARA 示例 1
a) 危害识别
“能够导致爆炸的装置的非预期能量释放”，这一危害被识别。 b) 危害事件
行驶速度低于 15km/h 可认为是所识别危害导致危害事件的驾驶场景。如果在此驾驶条件下相 关项发生失效导致非预期能量释放，储能装置可能会爆炸，对车辆乘员造成严重伤害。
c) 对识别出的危害事件分级 爆炸对车辆中的乘员导致危及生命的伤害，存活不确定：危害严重度可被估计为 S3。 车辆行驶速度低于 15km/h。基于对车辆目标市场的交通统计，这一条件在 1%～10%的驾驶时 间内发生：此场景的暴露概率可被估计为 E3。 车辆驾驶员或乘客控制相关项失效和装置爆炸的能力被认为是不可能的：可控性可被估计为 C3（难以控制或不可控）。
应用 GB/T 34590.3，表 4：ASIL 等级确定为 ASIL C。
6.2.3 HARA 示例 2
本章考虑非预期的能量释放的影响由于设计改进而从本质上被限制的情况。这将导致如下的HARA：
a) 危害识别
“能够导致爆炸的装置的非预期能量释放“作为一种危害，被识别。
b) 危害事件
对于所有驾驶场景，非预期能量释放不会导致危害事件。因此，相关项失效不会引起伤害。
c) 对识别出的危害事件分级
由于相关项的失效不会导致伤害，严重度评为 S0，无需确定可控性，也无需定义安全目标。
6.3 关于可控性分级的论述
如GB/T 34590.3，第6章中的解释，可控性代表对驾驶员或其他交通参与者能够避免特定伤害 的能力的预估。
在最简单的情况下，只考虑给定危害事件的一个后果，可控性代表了对避免此后果的可能性的预估。 然而，也可能存在其它情况。例如，可能有一个严重后果（例如：严重度S2），却很容易避免（例如： 可控性C1）；又或者后果的严重度较低（例如：S1），却难以避免（例如：C3）。假设暴露概率等级为 E4，下面几组数值是可能的结果，其说明了最高的严重度导致最高的ASIL 等级不是必然成立的。
——E4，S2，C1 => ASIL A；及
——E4，S1，C3 => ASIL B
在此示例中，ASIL B是危害事件的合理分级。
6.4 外部措施
6.4.1 总则
外部措施是独立于且不同于相关项的措施，用于降低或减轻相关项失效造成的风险。 注1：如果外部措施独立于相关项实施的功能，则外部措施可被在HARA中考虑。 注2：外部措施作为一种降低ASIL的技术假设，根据GB/T 34590.3，6.4.4.4被确认。
6.4.2 基于车辆的外部措施示例 1
车辆A装备手动变速箱，当熄火后，变速箱能处于任何档位，包括空档。车辆B装备自动变速箱，熄 火状态下，维持一个档位啮合且离合器常闭状态。两辆车都有附加相关项，电子驻车制动（EPB）。
对两辆车辆都分析的场景含：
——车辆处于驻车状态（熄火，驾驶员不在）
——车辆位于人口密集的的城市区域的有坡度的路边
——发生涉及电子驻车功能突然丧失的失效 在此场景中，对于车辆A，当熄火时被非预期地置于空档，如果无人看管，将可能溜车。这会导致
可控性评估为C3，取决于车辆附近是否有易受伤害的人员，严重度为S2或更高，且暴露概率等级大于E0。 依据实际分配的暴露概率等级，得出的ASIL等级在A和C之间或QM。
车辆B一直结合在档位上而不会发生移动，所以不会导致危害。此设计中包含的基于车辆的外部措 施有助于消除该场景下的风险，但前提是自动变速器和电子驻车系统能被证明是充分独立的。
6.4.3 基于车辆的外部措施示例 2
车辆A装备动态稳定控制系统和启停功能。车辆B只装备了启停功能。 对两辆车辆都分析的场景包含：
——车辆以中高速行驶（50km/h<v<90km/h）；
——路面平坦、干燥，且在郊区；
——车辆正在接近一个中等曲率的道路；
——车速和道路曲率会产生中高侧向加速度；及
——启停功能中的失效引起发动机非预期熄火，导致在此场景中突然失去驱动力。 作为突然丢失牵引力的后果，车辆会产生横摆力矩，这要求驾驶员调整方向盘以重新控制车辆。在
车辆B上执行这个动作可被证明具有更低的可控性，可导致高风险。此风险评级会依赖于分配的暴露概 率等级。相比之下，车辆A的动态稳定性控制功能会限制侧向不稳定的影响。结果是，车辆A的可控性等 级会更好。因此，由动态稳定性控制提供的基于车辆的外部措施有助于这种情景下风险的降低。然而， 仅当能证明所考虑的启停功能失效不会影响动态稳定性控制功能时，才适用这种情况。
注：此示例中使用的危害的深入分析，可在参考文献[6]中找到。
6.5 合并安全目标的示例
6.5.1 介绍
安全目标是相关项的顶层安全要求。它们导出避免危害事件产生不合理风险所需的功能安全要求。 按照GB/T 34590.3，6.4.4，概念阶段中会确定安全目标。当安全目标相似或涉及不同场景下的相 同危害时，它们可以被合并成以原始安全目标的最高ASIL等级为最终ASIL等级的一个安全目标。因为更 少的安全目标将被管理，但仍覆盖了所有识别出的危害，所以这能够简化后续的开发活动。
6.5.2 总则
下面示例中展示的相关项、安全目标和ASIL分级仅为了说明安全目标合并的过程。该示例不能反映 将GB/T 34590系列标准应用到相似真实项目的情况。特别是，它没有完整表述失效模式识别、场景分析 和整车层面的影响评估。
为简单起见，示例只限于两个安全目标的合并，但相同的方法可以扩展到更多初始安全目标的合并。
6.5.3 功能定义
考虑车辆装备了电子驻车制动（EPB）系统。当被驾驶员的特定请求激活时，EPB系统在车辆后轮施 加制动力矩以防止驻车时车辆非预期的移动。
6.5.4 应用于不同场景下相同危害的安全目标
6.5.4.1 危害分析和风险评估
为简化示例，只考虑驻车功能的如下失效模式：
——非预期的驻车制动激活。 注：在此上下文中，术语“非预期的激活”是指在没有驾驶员请求的情况下的功能动作。 根据故障发生时的特定场景，此失效模式会导致不同的车辆影响，如表1所示。
现成译文，到款即发。
任取样页验证译文质量。
提供正规增值税电子发票。
请联系手机/微信: 133-0649-6964/Email: standardtrans@foxmail.com 购买完整译文。
专业源于专注|ChinaAutoRegs 始终专注于汽车标准翻译领域！迄今为止已翻译上千个国内外汽车标准法规！独家打造千万级汽车专业术语库和记忆库。
Note:
This document in English is readily available, and delivered immediately upon payment.
You may request for sample pages to your preference before placing an order.
Please contact standardtrans@foxmail.com for the complete PDF in English.