编号	文档
Ref [1]	UL 4600: UL Standard For Safety Evaluation of Autonomous Products
Ref [2]	ISO 26262-1: Road vehicles- Functional safety- Part 1: Vocabulary
Ref [3]	ISO 26262-2: Road vehicles- Functional safety- Part 2: Management of functional safety
Ref [4]	ISO 26262-3: Road vehicles- Functional safety- Part 3: Concept phase
Ref [5]	ISO 26262-5: Road vehicles- Functional safety- Part 5: Product development at the hardware level
Ref [6]	ISO 26262-8: Road vehicles- Functional safety- Part 8: Supporting processes
Ref [7]	ISO 26262-9: Road vehicles- Functional safety- Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses

2.2 国内标准和技术规范

本规范参考的国内标准和技术规范如表 3 所示。

表 3 规范性引用文件

编号	文档
Ref [1]	GB/T 34590.1: 道路车辆功能安全第 1 部分：术语
Ref [2]	GB/T 34590.2: 道路车辆功能安全第 2 部分：功能安全管理
Ref [3]	GB/T 34590.3: 道路车辆功能安全第 3 部分：概念阶段
Ref [4]	GB/T 34590.5 : 道路车辆功能安全第 5 部分：产品开发：硬件层面
Ref [5]	GB/T 34590.9 : 道路车辆功能安全第 9 部分：以汽车完全完整性等级为导向和以安全为导向的分析
Ref [6]	GB/T 20438: 电气 / 电子 / 可编程电子安全相关系统的功能安全

3 术语缩写与定义

3.1 缩写

表 4 列出了本规范中专有名词的英文全称及相应的中文。

表 4 缩写

缩写	含义
ASIL	Automotive Safety Integrity Level ( 汽车安全完整性等级 )
HSI	Failure Mode and Effects Analysis ( 失效模式与影响分析 )
ECU	Electronic Control Unit ( 电子控制单元 )
PMHF	Potentially Mission Hazardous Failures ( 潜在的任务危害故障 )
EMI	Electromagnetic Interference ( 电磁干扰 )
SEooC	Safety Element out of Control ( 失控的安全要素 )
SPFM	Single Point Fault Metric ( 单点故障度量指标 )
LFM	Latent Fault Metric ( 潜在故障度量指标 )
EEC	Electronic Engine Control ( 电子发动机控制 )
ASIC	Application-Specific Integrated Circuit ( 应用特定集成电路 )
SoC	System on a Chip ( 片上系统 )
RAM	Random Access Memory ( 随机存取存储器 )
SPOF	Single Point of Failure ( 单点故障 )
IMU	Inertial Measurement Unit ( 惯性测量单元 )
GPS	Global Positioning System ( 全球定位系统 )
FPGA	Field Programmable Gate Array ( 现场可编程门阵列 )
BMS	Battery Management System ( 电池管理系统 )

3.2 术语和定义

技术安全

通过运用各种技术手段，旨在预防或减轻由于车辆智能系统的失效或误判而导致的碰撞、伤害甚至致死事件的发生概率。

技术安全要求

为实现相关的功能安全要求而得出的要求。

硬件安全要求

确保智能驾驶系统及其相关硬件在各种可能的情境下都能正常运作，并且不会对乘客、行人以及其他道路使用者造成不可接受的风险而设立的一系列准则和规范。

协调

指的是在硬件设计和实施过程中确保不同组件和系统之间的兼容性、同步性和一致性。

系统架构设计

指在开发自动驾驶智能系统时确定其整体结构和组件之间关系的过程。

整体硬件架构

指组成自动驾驶车辆所有关键硬件组件的系统设计，以确保车辆能够安全、可靠地执行自动驾驶任务。

硬件架构特性

硬件部分的架构特性涉及多个方面，这些特性共同确保了自动驾驶系统的安全性、可靠性和有效性。

硬件架构设计

针对特定应用场景和功能需求，对组成智能驾驶车辆的各类电子电气部件（如传感器、控制器、执行器等）进行统筹规划和布局，构建出具有高效性能、高可靠性和易于维护特点的物理实体框架。

硬件详细设计

针对构成智能驾驶车辆硬系统的各个硬件设备及其接口进行具体的物理组件进行具体的技术规划和实现。

软硬件接口

指硬件组件和软件系统之间进行数据交换和通信的桥梁，用于实现两者之间的数据交互和协调工作。

生命周期

相关项从概念到报废的全部阶段。

机电硬件元器件

指构成智能驾驶车辆物理部分的各类电子、机械和机电一体化的组件。

随机硬件失效

在硬件要素的生命周期中，发生的服从概率分布的不可预测的失效。

随机硬件故障

服从概率分布的硬件故障。

硬件内部失效

指的是硬件组件在设计、制造、装配或使用过程中由于各种原因出现的故障或性能下降。这些失效可能导致车辆的自动驾驶功能受到限制或完全丧失。

硬件外部失效

由外部因素导致的硬件组件故障或性能下降。

安全故障

指系统在发生故障时，能够保证采取的措施或进入的状态不会对乘客、行人或其他车辆造成不合理的安全风险。

瞬态故障

指硬件组件在短时间内发生的暂时性功能异常或性能下降。这种故障通常不会对硬件造成永久性损害，但可能对车辆的自动驾驶功能产生短期影响。

单点故障

指系统中的一个组件或部件发生故障，而这个故障可能会导致整个系统或子系统失效的情况。

残余故障

某个硬件组件发生故障后，尽管采取了一定的措施进行处理或修复，但该组件仍保留有潜在的故障或性能下降的风险。

多点故障

在未被探测且未被感知到的情况下，与其他独立故障组合可能导致一个多点失效的一个故障。

潜伏故障

一种在系统正常运行时不易被检测到的故障，它可能由于设计缺陷、制造缺陷、材料退化或环境因素等原因存在，但在特定的触发条件下才显现出来。

看门狗定时器

是一种安全机制，用于确保系统在发生故障时能够安全地恢复到已知状态或采取特定的安全措施。看门狗定时器的主要作用是监控系统的运行状态，检测并响应异常情况。

不稳定输出

由硬件组件产生的数据或信号出现变异或不可靠的情况，这些不稳定的输出可能

会对自动驾驶系统的决策和执行产生负面影响。

任务剖面

对智能驾驶车辆在其预期使用场景中所需执行的任务、环境条件、性能要求和操作模式的详细描述。

故障容错时间间隔

指在发生故障的情况下，系统能够正常运行的时间长度，而不需要立即进行人工干预或系统停机。

最大故障处理时间间隔

指从系统检测到故障发生到系统采取措施（如故障处理、安全停车或降级运行）的最长时间限制。

暴露持续时间

指的是硬件组件在特定的环境条件下被暴露的时间长度。

诊断覆盖率

指通过内置的诊断系统能够检测和识别出的潜在问题、故障或异常情况的比例。

失效模式

指硬件系统在运行过程中可能出现的各种故障或异常行为。

失效率

指单位时间内硬件系统发生故障的比例。

失效率单位

合适的失效率度量单位对于确保系统在整个生命周期内的性能至关重要。

粒度水平

指在系统设计、分析和维护过程中，对系统组件或子系统的分解和抽象的详细程度。

分层设计

是一种结构化的设计方法，通过将系统分解为多个交互的层次来简化复杂性、增强模块化，并提高系统的可维护性和可扩展性。

鲁棒性设计

在无效输入或有压力的环境条件下，具有正确工作的能力的设计。

安全相关要素

有潜在可能导致违背安全目标或有助于实现安全目标的要素。

安全相关功能

有潜在可能导致违背安全目标或有助于实现安全目标的功能。

演绎分析

是一种自上而下的方法，用于理解和评估系统的结构、功能和性能。

归纳分析

是一种自下而上的分析方法，侧重于从细节出发，逐步向上构建对系统整体的理解。

故障探测

故障探测机制能够在硬件出现故障时及时识别问题，从而允许系统采取适当的措施，如警告驾驶员、执行安全策略或进行自我修复

故障注入

是一种模拟技术，用于在开发和测试阶段评估系统的容错能力和故障管理策略。通过有意识地引入故障到硬件或软件中，可以验证系统的响应和恢复机制是否符合设计要求。

比较器

指用于比较两个或多个信号或值的电子组件。

多数表决电路

是一种用于提高系统容错能力和可靠性的电路设计技术，这种电路通过冗余和投票机制来确定最终的输出，即使部分输入信号出现故障或错误，也能确保系统的正常运行。

3.3 约定术语

本文档中使用了下列术语：

 “ 强制性 ” ：表示不允许出现安全案例偏差

 “ 需要 ” ：表示仅当通过提示证明提示元素与项目和 / 或其安全案例本质上不兼容时，才允许发生安全案例偏离。

 “ 强烈推荐 ” ：表示是应该遵循的最佳实践，但可以省略，尤其是对于低风险项目。安全案例中明确指出了遗漏，并提供了合理的支持理由，以提供一个根源，以便将根本原因分析追溯到这些遗漏。只要以合理的理由记录了这些遗漏，就可以认为该安全案例是可以接受的。

 “ 推荐 ” ：表示这些是可选的提示元素，记录了良好做法和 / 或有用技术的建议。

 “ 注 ” 或 “ 示例 ” ：表示的信息仅用于辅助理解或阐明相关要求，不应作为要求本身且不具备完备性。

4 硬件系统融合安全开发概述

4.1 概述

本规范确定了智能驾驶车辆实现产品安全的技术开发要求，这些要求及其工作成果统称为硬件系统融合安全开发，并且本规范也规定了组织具备相应融合安全能力的开发流程要求，具体章节内容：

注：其他专用的安全标准可作为本文件的补充条款使用，反之亦然。

a) 硬件层面产品开发概述 ( 请参阅第 5 章节 )

b) 硬件安全要求定义 ( 详情见第 6 章节 )

c) 硬件设计 ( 详情见第 7 章节 )

d) 硬件架构度量的评估 ( 详情见第 8 章节 )

e) 随机硬件故障导致违背安全目标的评估（详情见第 9 章节）

f) 硬件集成与验证 ( 详情见第 10 章节 )

$C:\Users\sys002\Desktop\硬件融合安全开发目录.jpg$

图 4.1 硬件系统融合安全开发规范整体架构

4.2 硬件系统融合安全开发目标

本规范的目标是：

a) 确定硬件开发各子阶段中所涉及的功能安全、预期功能安全和信息功能安全活动。

b) 定义硬件安全要求，并细化软硬件接口规范。

c) 定义在硬件全生命周期中的融合安全要求。

d) 创建并验证硬件设计。

e) 确定设计的硬件架构在与安全相关的随机硬件失效探测和控制的适用性

f) 提供随机硬件失效导致违背安全目标的残余风险足够低的证据。

g) 确保所开发的硬件符合硬件融合安全要求

4.3 硬件系统设计融合安全原理

$C:\Users\sys002\Documents\WeChat Files\wxid_q08yj2ozx37c22\FileStorage\Temp\1725783812216.png$

图 4.2 硬件系统融合安全原理

5 硬件层面产品开发初始化

5.1 硬件层面产品开发初始化概述

在硬件产品开发的启动阶段的目的是确定和规划在硬件开发的各个子阶段所涉及的功能安全、预期功能安全和信息功能安全活动，规定硬件融合安全活动计划包含在项目的安全计划中。

在硬件层面必要的活动和产品开发过程包括：

a) 技术安全概念的硬件实现 ( 请参阅第 5.2 章节 )

b) 分析潜在的故障及其影响 ( 详情见第 5.3 章节 )

c) 与软件开发的协调 ( 请参阅第 5.4 章节 )

5.2 技术安全概念的硬件实现

智能驾驶安全标准中技术安全概念的硬件实现涵盖了多个关键方面，这些硬件组件共同协作，以确保智能驾驶系统的可靠性、稳定性和安全性，以下是对这些硬件实现方面的详细归纳：

a) 感知硬件

1) 摄像头

2) 雷达

3) 惯性测量单元 (IMU)

注 1 ：提供车辆的姿态信息，结合 GPS 等定位系统实现精确定位和导航。

4) 其他传感器

b) 控制硬件

1) 制动与转向控制系统

2) 动力系统接口

3) 电机

4) 转向器

5) 刹车器

6) 变速器

c) 计算平台

1) CPU 计算单元

2) AI 单元

3) MCU 控制单元

4) 存储器

5) ISP

d) 通信硬件

1) 通信接口

2) 天线与射频模块

3) 车载通信模块

4) 卫星导航模块

5) 无线电通信硬件

示例：车对车通信、车对基础设施通信以及与云服务的交互。

e) 安全硬件

1) 安全芯片

2) 加密模块

3) 安全传输模块

4) 身份认证模块

5) 访问权限管理模块

f) 电源管理

1) 电能转换

2) 电能分配

3) 电源检测和保护

4) 电源优化

示例：智能电源管理系统可以根据车辆的实际需求动态调整各系统的供电电压和电流，以达到节能降耗的目的。

注 1 ：考虑过压、过流和短路保护等问题，以保障电气安全。

5.3 硬件潜在的故障及其影响

5.3.1 硬件潜在故障

硬件的潜在故障是指对运行中的设备如不采取预防性维修和调整措施，再继续使用到某个时候会发生的故障。这种故障在发生前通常会有一些预兆，即设备的功能性故障即将发生，但其尚未直接表现为功能性故障。

潜在故障可识别的物理参数表明了一种即将发生的功能性故障的预兆，功能性故障则表明设备丧失了规定的性能标准。

对硬件的潜在故障进行分析，主要基于以下几个方面的原因：

a) 预防功能性故障

1) 通过分析潜在故障，可以提前识别出设备即将发生的功能性故障，从而有足够的时间来采取预防措施，避免设备在实际运行中突然失效。

2) 潜在故障分析有助于延长设备的正常运行时间，减少因设备故障而导致的停机时间和维修成本。

b) 提高设备可靠性：

1) 对潜在故障进行深入分析，可以揭示设备设计和制造中的潜在问题，为改进设备设计、提高制造质量提供重要依据。

2) 通过优化设计、改进材料选择、加强制造工艺等措施，可以显著提高设备的可靠性和耐用性。

c) 保障系统安全：

1) 在智能驾驶领域，硬件的潜在故障可能导致系统性能下降或完全失效，从而对人员安全造成威胁。

2) 对潜在故障进行及时分析并采取相应的预防措施，可以显著降低系统失效的风险，保障人员安全。

d) 优化维修策略：

1) 通过分析潜在故障的发生规律和特点，可以制定合理的维修计划和维修策略。

示例：在潜在故障阶段进行预防性维修，可以避免设备进入耗损故障期后维修成本的大幅增加；同时，也可以避免过剩维修或维修范围扩大导致的资源浪费。

5.3.2 硬件潜在故障影响

硬件潜在故障的影响是多方面的，不仅会影响设备的正常运行，还可能对系统稳定性、安全性、可靠性以及经济效益等造成严重影响。以下是对硬件潜在故障影响的详细分析：

a) 硬件系统稳定性

1) 系统崩溃或死机：硬件潜在故障可能导致系统突然崩溃或死机，使得车辆使用者无法正常使用车辆设备。

示例：这种故障可能由多种原因引起，如内存泄漏、硬盘损坏、电源故障等。

2) 性能下降：潜在故障可能导致设备性能逐渐下降，如处理速度变慢、响应时间变长等。

b) 硬件系统安全性

1) 数据泄露：硬件潜在故障可能导致系统出现安全漏洞，使得敏感数据容易被窃取或泄露。

示例：硬盘故障可能导致数据无法加密或安全存储，从而增加数据泄露的风险。

2) 易受攻击：潜在故障可能使系统更容易受到外部攻击，如黑客入侵、病毒传播等。

c) 硬件系统可靠性

1) 频繁故障：硬件潜在故障可能导致设备频繁出现故障，影响系统的正常运行。

2) 降低可用性：潜在故障会降低硬件系统的可用性，使得硬件系统无法持续稳定地提供服务。这会对企业的业务连续性造成严重影响，甚至导致经济损失。

d) 增加硬件系统维护成本

1) 维修费用增加：硬件潜在故障需要更多的维修和保养工作，从而增加系统的维护成本。

示例：更换故障部件、修复损坏设备等费用。

2) 停机时间延长：潜在故障可能导致系统停机时间延长，影响企业的生产效率和经济效益。

e) 其他影响

1) 用户信任度下降：频繁的硬件故障会降低用户对设备的信任度，影响品牌形象和口碑。

2) 安全隐患增加：潜在故障可能增加系统的安全隐患。

5.3.3 硬件潜在故障分析

在智能驾驶的硬件产品开发层面，分析潜在的故障及其影响是确保产品安全性和可靠性的关键步骤，结合智能驾驶安全标准 ISO 21434 、 UL 4600 、 GB/T 43267 、 ISO 26262 等标准，提出一个系统性的分析方法可供借鉴，如下图所示：

$C:\Users\sys002\Downloads\硬件潜在故障分析2.0.drawio.png$

图 5.1 硬件潜在故障分析框架

a) 明确安全需求和标准遵循

1) 规定硬件安全需求，应参考参考技术安全概念和系统安全规范，其次应该验证硬件安全需求与技术安全概念和系统安全规范一致，并详细的描述

软硬件接口规范 HSI 。

2) 结合 ISO 26262 、 ISO 21448 、 ISO 21434 、 UL 4600 等安全标准中有关硬件系统所应遵循的规定，如下表所示：

表 1 各安全标准涉及的硬件内容

标准名称

涉及内容

UL 4600( 自动驾驶综合安全标准 )

a) 建立硬件安全案例

b) 建立硬件故障模型

1) 微电子和电子硬件故障模型

2) 传感器故障模型 ( 与自动驾驶相关 )

3) 电子和电气故障模型

4) 机械和非电子故障模型

5) 硬件项目级故障模型

c) 建立硬件运行故障模式和清单

d) 确定硬件故障的风险缓解行为

……

ISO 26262( 道路车辆功能安全 )

a) 硬件需求分析

b) 硬件安全性能评估

c) 硬件配置管理

d) 硬件安全机制

……

ISO 21448( 道路车辆预期功能安全 )

a) 硬件的可靠性、耐久性、兼容性

b) 硬件与软件集成

1) 软硬件接口

2) 通讯协议

……

ISO 21434( 道路车辆网络安全管理 )

a) 硬件组件安全审查

b) 硬件物理防御措施

1) 安全密封

2) 封锁

3) 防拆卸

c) 硬件组件的加密通讯

1) 加密

2) 数字证书

……

b) 系统架构设计

1) 基于安全需求和标准，设计合理的系统架构。这包括硬件的功能分配、接口定义、数据交换等，确保系统整体的安全性。

2) 在架构设计中，需要考虑到硬件的冗余设计、故障检测与隔离机制等，以减少单点故障对整个系统的影响。

c) 故障模式和影响分析（ FMEA ）

这里用 UL 4600 中提到的故障模式和影响分析方法用于识别和评估硬件产品中的潜在故障模式及其影响。

具体步骤：

1) 确定要进行 FMEA 的硬件系统或组件。

2) 识别潜在的故障模式，考虑硬件的硬件设计、制造工艺、使用环境等因素。

3) 为每个故障模式分配合适的严重级别，评估其对系统安全性和可靠性的影响。

4) 识别潜在的故障原因，包括设计失误、制造缺陷、外部环境因素等。

5) 评估故障的发生概率和检测概率，计算风险优先级数。

6) 提出改进措施，降低故障发生的概率或减轻故障的影响。

注 1 ：所用的方法只是一种通用的分析工具，适用于大多数的硬件故障。

注 2 ：若在企业实际项目案例中遇到的极端故障情况可进行更具体的分析。

d) 安全验证与测试

1) 进行单元测试、集成测试和系统测试，以确保硬件产品在各种情境下都能正常工作。

2) 模拟潜在的故障场景，验证故障检测、隔离和恢复机制的有效性。

e) 持续监控与改进

1) 在产品生命周期内，对硬件产品进行持续监控，收集并分析运行数据，及时发现潜在的安全隐患。

2) 根据监控结果和用户反馈，对硬件产品进行必要的改进和升级，确保产品的安全性和可靠性。

5.4 硬件与软件的协调开发

进行硬件与软件的协调开发在智能驾驶系统中具有至关重要的意义。以下是几个主要原因：

a) 提高系统整体性能

1) 功能互补：硬件提供物理基础和执行能力，而软件则赋予系统智能和决策能力。两者相互补充，共同实现系统的整体功能。

2) 优化匹配：通过协调开发，可以确保硬件与软件在性能上相互匹配，避免资源浪费或性能瓶颈。例如，软件的算法复杂度应与硬件的计算能力相匹配，以确保系统能够高效运行。

b) 提升系统稳定性与可靠性

1) 减少冲突：协调开发可以减少硬件与软件之间的接口冲突和兼容性问题，降低系统故障率。

2) 故障隔离：在系统设计时，通过合理的软硬件划分和接口定义，可以实现故障隔离。

示例：当某个硬件或软件模块出现故障时，不会影响到整个系统的正常运行。

c) 降低开发成本与时间

1) 并行开发：协调开发允许硬件和软件团队并行工作，减少等待时间，加快项目进度。

2) 资源共享：通过共享设计文档、测试工具等资源，可以提高开发效率，降低开发成本。

d) 满足安全标准与法规要求

1) 安全性设计：在智能驾驶系统中，安全性是至关重要的。协调开发可以确保硬件与软件在安全性设计上相互协调，满足 ISO 26262 、 ISO 21434 等安全标准的要求。

2) 合规性：不同国家和地区对智能驾驶系统有不同的法规要求。协调开发可以确保系统在设计时就考虑到这些法规要求，避免后续合规性问题。

e) 促进技术创新与升级

1) 技术融合：通过协调开发，可以促进硬件与软件技术的融合创新，开发出更加先进、高效的智能驾驶系统。

2) 快速迭代：在软件定义汽车的时代，软件在高速迭代。协调开发可以确保硬件与软件之间的接口保持相对稳定，同时支持软件的快速迭代和升级。

6 硬件安全要求

6.1 硬件安全要求概述

硬件安全要求是指与自动驾驶汽车硬件设计和操作有关的一系列规则、准则或目标，旨在确保硬件能够可靠地执行其功能，并最大程度减少因硬件失效而导致的风险。

将技术安全要求分配给硬件和软件。既分配给硬件又分配给软件的要求被进一步划分出仅对硬件的安全要求。考虑设计限制和这些限制对硬件的影响 , 对硬件安全要求进行进一步

本章的目的是：

a) 定义硬件安全要求 ( 请参阅第 6.2 章节 )

b) 细化软硬件接口规范定义 ( 请参阅第 6.3 章节 )

c) 验证硬件安全要求及软硬件接口规范与技术安全概念及系统架构设计规范的一致性 ( 请参阅第 6.4 章节 )

6.2 硬件技术安全要求

硬件安全要求是旨在达到并确保所需硬件融合安全等级的要求，在安全生命周期过程中 , 硬件技术安全要求通过分层结构进行定义和细化。

注 1 ：安全要求应该分配给硬件和软件，既分配给硬件又分配给软件的要求被进一步划分出仅对硬件的安全要求。

注 2 ：考虑设计限制和这些限制对硬件的影响 , 对硬件安全要求进行进一步的细化。

图 4 给出了本规范中中用到的硬件安全要求的结构和相关性：

a) 安全要求被分配给要素或在要素间分布

b) 安全要求的管理包括对要求达成一致、从安全要求的执行方取得承诺和保持追溯性

c) 为了支持对安全要求的管理 , 推荐使用合适的需求管理工具

d) 列出了关安全要求内容在不同层面的特定要求

e) 相关项硬件要素的硬件安全需求规范应从分配给硬件的技术安全要求中导出

f) 软件系统技术安全要求相关的部分也包括在系统安全技术要求中

图 6.1 硬件技术安全需求框架

从系统技术需求层面硬件技术安全导出的具体流程包括：

a) 相关项硬件要求 ( 请参阅第 6.3 章节 )

b) 硬件安全机制 ( 请参阅第 6.4 章节 )

c) 硬件安全目标指标 ( 请参阅第 6.5 章节 )

d) 硬件安全要求验证 ( 请参阅第 6.6 章节 )

e) 软硬件接口规范 ( 请参阅第 6.7 章节 )

6.3 相关项硬件要求

相关项硬件的硬件安全需求规范应该从分配给硬件的技术安全要求中导出。

6.3.1 系统功能定义

车辆系统功能定义的要求是确保系统能够准确、可靠、安全地执行其预定任务，同时满足用户需求、法规要求以及技术可行性。

注 1 ：符合危害分析和风险评估章节所列举的相关要求，以及必须要包含的内容。

注 2 ：本节以电池管理系统 (BMS) 为例进行简单说明。

电池管理系统的主要功能总结如图 1 所示。其中，电池参数采集及故障诊断和通讯及存储是 BMS 的基础功能，实现对电池工作状态的监测以及与其他电子控制单元 (Electronic Control Unit ， ECU) 之间的信息交互。电池状态估计和充放电管理的精度是评判 BMS 性能的重要指标，也是影响电池寿命的关键因素。安全防护功能对整车高压回路安全和人员安全进行监测和防护。

图 6.2 电池管理系统功能

6.3.2 系统接口

基于系统的实现功能，需要通过一系列的接口与其他车载系统进行信息交互。

硬件接口通常包括物理接口和通信协议两个方面。物理接口定义了硬件之间如何连接，如接口类型、连接器规格等；而通信协议则规定了数据如何在这些接口上传输，包括数据传输速率、数据包格式、错误检测与纠正机制等。

在智能驾驶系统中，硬件接口通常包括以下两种类型：

a) 物理接口

1) 以太网接口：

用于高速数据传输，支持摄像头、雷达等设备接入。

2) CAN/CAN-FD 接口：

控制器局域网接口，广泛应用于汽车内部通信，支持多种传感器和执行器的接入。

3) GMSL 接口：

Gigabit Multimedia Serial Link 接口，专为汽车摄像头等高速视频数据传输设计。

4) Automotive-Ethernet 接口：

汽车以太网接口，支持更高的数据传输速率和更低的延迟

5) 其他串行和并行接口：

RS232 、 RS485 、 USB 等，根据具体需求选择。

b) 通信协议

1) TCP/IP 协议族：

用于以太网通信，支持数据传输、路由、网络管理等功能。

2) CAN 协议：

控制器局域网协议，用于汽车内部设备之间的通信。

3) 其他专用协议

如 SDK 、 GB/T 28281 、 RTSP 等，根据设备类型和应用场景选择。

为了确保智能驾驶系统各组件之间能够稳定、安全、高效地通信与协作，从而实现整体系统的功能、性能和安全性目标，硬件接口的设计也应满足如下的要求：

a) 安全性

接口设计必须考虑网络安全和物理安全，防止未授权访问和数据泄露。 ISO 21434 和 ISO 26262 均强调了对安全性的要求，包括在接口设计中实施适当的安全控制措施。

b) 可靠性

接口应能在各种环境条件下稳定运行，包括高温、低温、振动等恶劣条件。这要求接口具有良好的耐用性和容错能力。

c) 兼容性

接口设计应支持不同厂家生产的设备和系统之间的互操作性，以促进智能网联汽车生态系统的健康发展。

d) 高效性

接口设计应支持高速数据传输，以满足智能驾驶系统对实时性和准确性的要求。

e) 可扩展性

接口应能够支持新设备和功能的接入，以满足未来智能驾驶硬件系统的升级需求

6.3.3 系统运行环境

进行项目的运行环境定义是项目管理中极为重要的一环，它直接关系到项目的成功执行与最终成果的质量，有利于明确项目的范围、限制条件和外部因素，是项目不会偏离既定的目标。

电动汽车 BMS 放置在电池包内部与动力电池相邻 , 电池包通常布置在电动汽车底盘因此 BMS 的运行环境相对恶劣，包括 :

a) 电磁环境

强电磁辐射干扰 :

示例：由于电机驱动和电池充放电等因素， BMS 运行环境中存在强电磁辐射干扰。

b) 温度环境

极寒与酷暑 :

示例：电动汽车可能行驶在极端气候条件下，包括极寒的冬季和酷热的夏季。

c) 机械环境

强振动和机械冲击 :

示例：电动汽车在行驶过程中会经历各种路况和驾驶行为，导致车辆和电池组产生振动和机械冲击。

d) 防水与绝缘

高压电绝缘和防水问题：

示例： BMS 直接管理电池组的高压电，因此必须具备优异的绝缘性能以防止漏电和短路。同时，由于电动汽车可能行驶在潮湿或多雨的环境中， BMS 还需要具备良好的防水性能，确保内部电路和元器件不受水分侵蚀。

e) 其他环境因素

盐碱度高的环境：

示例：在沿海或盐碱度高的地区，空气中的盐分和湿度可能对 BMS 的外壳、接口和内部元器件造成腐蚀。

6.3.4 硬件系统故障模型

故障模型是对系统可能发生的故障及其影响的描述，确保系统在发生故障时能够保持安全状态或转入降级模式，需要为每个与安全相关的项目组件，功能部件或与故障分析相关的其他方面确定的故障模型，定义故障模型的具体步骤如下：

a) 识别硬件组件

需要明确系统中包含哪些硬件组件，包括传感器、处理器、执行器等。

b) 分析故障模式

对每个硬件组件进行故障模式分析，识别可能的故障类型，如开路、短路、性能退化等。

c) 评估故障影响

分析每种故障模式对系统性能和安全性的影响，确定其严重程度和可能导致的后果。

d) 建立故障模型

根据分析结果，建立硬件系统的故障模型。这可以通过图形化表示（如故障树、事件树等）或数学模型来实现。

e) 验证和测试

对建立的故障模型进行验证和测试，确保其准确性和可靠性。这可以通过模拟故障情况、进行实际测试等方式来完成。

f) 制定预防措施

根据故障模型的分析结果，制定相应的预防措施和应急计划，以降低故障发生的风险和影响。

下面将以 “ 车 - 路 - 云 ” 系统所涉及的硬件部分进行相关故障模型的定义示例说明。

g) 识别硬件组件

1) 车辆端：

传感器：摄像头、雷达、 LiDAR 、超声波传感器、惯性测量单元（ IMU ）等。

控制器：自动驾驶计算平台、 ECU 、制动控制器、转向控制器等。

执行器：制动系统、转向系统、油门控制器等。

通信模块： V2X 通信模块、 GPS 定位模块等。

2) 道路基础设施端：

交通信号控制系统：信号灯、信号控制机、交通监控摄像头等。

路侧单元（ RSU ）：负责与车辆通信的设备。

环境监测设备：气象站、能见度检测仪、路面状态传感器等。

3) 云端系统：

服务器：处理数据、存储信息的服务器集群。

网络设备：路由器、交换机、防火墙等。

数据中心基础设施：电力供应系统、冷却系统、安全设施等。

h) 分析故障模式

对每个硬件组件进行详细的故障模式分析，识别可能的故障类型，包括但不限于：

1) 电气故障：开路、短路、电源波动等。

2) 机械故障：磨损、断裂、松动等。

3) 软件故障：固件错误、软件崩溃、通信协议问题等。

4) 环境因素：天气影响（如雨、雪、雾）、电磁干扰、物理损坏等。

5) 性能退化：随时间和使用而逐渐降低的性能。

i) 评估故障影响

分析每种故障模式对车路云一体化系统性能和安全性的影响，包括：

1) 对车辆行驶安全的影响，如碰撞风险、失控风险。

2) 对交通流畅度的影响，如交通拥堵、信号延误。

3) 对数据完整性和隐私保护的影响，如数据丢失、泄露。

4) 对系统可靠性和可用性的影响，如服务中断、恢复时间。

j) 建立故障模型

根据分析结果，建立车路云一体化的硬件故障模型。这可以通过以下方式实现：

1) 故障树分析（ FTA ）：从系统级故障开始，逐级分解到各个硬件组件的故障模式，形成逻辑树状图。

2) 事件树分析（ ETA ）：从某个初始事件出发，模拟不同故障模式及其后续影响，形成事件序列图。

3) 状态空间模型：描述系统在不同状态下的行为，包括正常状态和故障状态。

4) 数学模型：使用概率论、排队论等数学工具对故障进行量化分析。

k) 验证和测试

对建立的故障模型进行验证和测试，确保其准确性和可靠性。这可以通过以下方式进行：

1) 模拟测试：使用仿真软件模拟各种故障情况，观察系统响应。

2) 实验室测试：在受控环境中对硬件组件进行故障注入测试。

3) 现场测试：在真实道路环境中进行实地测试，验证系统在实际运行中的表现。

l) 制定预防措施

根据故障模型的分析结果，制定相应的预防措施和应急计划，包括：

1) 冗余设计：在关键硬件组件上实现冗余，以提高系统的容错能力。

2) 定期维护：制定硬件组件的定期维护和检查计划。

3) 故障预警系统：开发故障预警算法，提前发现潜在故障并采取措施。

4) 应急响应计划：制定针对不同故障情况的应急响应计划，确保故障发生时能够迅速恢复系统正常运行。

6.4 硬件安全机制

智能驾驶硬件安全机制是指为了确保智能驾驶系统在各种复杂和潜在危险的环境中能够稳定运行，并保护乘客、车辆及周围环境安全的一系列硬件设计、配置和防护措施。这一机制涵盖了从传感器、控制器到执行器等各个关键硬件组件的安全要求，以及它们之间的交互和协同工作。

6.4.1 对于每个使相关项实现安全状态或维持安全状态的安全机制 , 应定义下列内容

a) 状态间的转换

注 1: 包括控制执行器的要求。

b) 与从适当的架构层级分配得到的时间要求相关的故障处理时间间隔

注 2: 该子要求的目的是在针对每个安全目标定义的故障处理时间间隔的范围内 , 实现时间一致。

c) 不能在 FTTI 内进入相关项安全状态时的紧急运行容错时间间隔。

注 3: 整车测试和试验能够用于确定紧急运行容错时间间隔。

示例 1: 安全状态之前的降级运行持续时间。

示例 2: 一个依赖于电源的线控制动应用的安全机制 , 可以包括定义备用电源或储能设备 ( 容量、启动和运行时间等 )

6.4.2 硬件安全要求应满足系统技术安全要求中的安全机制的故障容错时间间隔，或者最大故障处理时间间隔

注 1: 硬件设计中能定义一种能够控制故障 , 但不能满足容错时间间隔或最大故障处理时间间隔的机制。在这种情况下 , 进行本文件的第 8 章和第 9 章的定义的度量评估和 ASIL 等级分解时 , 不能考点该机制

a) 与系统自身故障的探测、指示和控制相关的安全机制

注 1: 包括用于探测随机硬件故障及探测系统性故障 ( 如果适用 ) 的系统自身监控。

注 2: 包括对通信通道失效 ( 例如 : 数据接口、通信总线、无线射频链接 ) 的探测和控制的安全机制。

注 3: 可以在系统架构适当的层级定义安全机制。

b) 涉及探测、指示和控制与本系统有相互影响的其他外部要素中所发生故障的安全机制。

示例 : 外部设备包括其他的电控单元、电源或者通信设备。

c) 使系统实现或者维持在相关项的安全状态的安全机制 ;

注 4: 包括来自安全机制的多个控制请求的仲裁。

d) 定义和执行报警和降级策略的安全机制

e) 防止故障处于潜伏故障的安全机制

注 5: 如同 a)~d), 这些安全机制通常与上电过程 ( 运行前检查 ), 运行中 , 下电过程 ( 运行后检查 ) 及维护过程中发生的自检相关。

6.5 硬件安全需求

6.5.1 相关项硬件要素的硬件安全需求规范应从分配给硬件的技术安全要求中导出

a) 审查系统技术安全，识别出与硬件直接相关的安全要求。

b) 将与硬件相关的系统技术安全要求进一步细化为具体的硬件安全需求。

c) 考虑硬件的特性和限制条件，结合环境条件、适用范围等导出适合于硬件的设计和实现方式。

例子 : 车载电源系统需要设计有冗余和稳压机制，以应对供电电压的波动。同时，采用高效的电源管理策略，如动态调整供电电压和电流，以满足不同硬件组件的用电需求。

6.5.2 硬件安全需求规范应包括与功能安全、预期功能安全、网络信息安全有关的每一条硬件要求，包括以下内容：

a) 为控制要素硬件内部失效的硬件安全要求和安全机制的相关特性。这包括用于覆盖瞬态故障的内部安全机制。

例子：由于所使用的技术而产生的瞬态故障。

b) 为控制或者容忍要素外部失效的硬件安全要求和安全机制的相关特性。

例子：对传感器或执行器的诊断

c) 为符合其他要素的安全要求的硬件安全要求和安全机制的相关特性。

d) 为探测内外部失效和发送失效信息的硬件安全要求和安全机制的相关特性。

e) 为与网络安全活动有关的硬件组件进行网络硬件安全需求规划。

例子 1 ：敏感数据（如用户个人信息、车辆行驶轨迹等）在传输和存储过程中应进行加密处理，以防止被未经授权的第三方窃取或篡改。硬件应支持高效的数据加密算法和密钥管理机制。

例子 2 ：硬件设备在接入智能驾驶系统前应进行严格的安全认证和测试，确保其符合相关的安全标准和规范。这有助于防止恶意设备或软件通过硬件接口进入系统内部造成破坏。

f) 应使硬件具有基本的能力边界识别能力，要求硬件在设计时就要考虑到不同场景下的适用性和局限性。

e) 不定义安全机制的硬件安全要求。

6.6 硬件安全要求定义

为了达到 6.4.2 中所列安全要求的特性 , 应使用以下恰当的组合来定义安全要求 :

a) 自然语言 ;

b) 表 2 所列的方法。

表 2 硬件安全要求定义方法

方法		ASIL 等级
方法		A	B	C	D
1a	用于要求定义的非形式记法 a,b	＋＋	＋＋	＋	＋
1b	用于要求定义的半形式记法 a,b,c,d	＋	＋	＋＋	＋＋
1c	用于要求定义的形式标记法 a	＋	＋	＋	＋
a 安全要求定义方法的恰当选择考虑 : 针对特定问题待定义的安全要求 , 方法是否足够准确以具备 6.4.2 规定的安全要求的特性 ; 方法的复杂性 ; 定义或管理安全要求的人员的背景知识。示例包括使用状态图或关系图来定义硬件的复杂行为 , 包括许多状态或 / 和复杂转换。 b 对于较高层面的安全要求 ( 如安全目标、功能安全要求和技术安全要求 ), 自然语言和其他类型的非形式记法是最恰当的形式 , 然而有些要求可能用半形式记法更好处理。 c 半形式记法使用数学或图形要素补充的自然语言来表达需求 , 如方程、图形、图表、流程图、时序图和许多其他形式的表示 ( 例如 ,UML 和 SysML) 。示例包括基于模型的技术 , 以及在自然语言中为要求描述语句应用模板和受控词汇表。 d 对于较低层面的安全要求 , 其可能定义了精确的硬件和软件行为和能力 , 由于半形式记法更清晰 , 所以更合适。然而 , 即使这样 , 也难以或没有必要对每条要求都使用半形式技术。

6.6.1 安全要求应能被明确地识别为安全要求。

6.7 软硬件接口规范

智能驾驶软硬件接口规范是一个复杂而细致的过程，它涉及多个领域的技术标准和协议。以下是一个概括性的指导框架，用于编写智能驾驶软硬件接口规范：

图 6.3 软硬件接口涉及流程

a) 定义接口类型和功能

1) 接口类型：根据智能驾驶系统的需求，定义不同类型的接口，如数据接口、控制接口、通信接口等。

2) 功能定义：详细描述每个接口的功能、输入输出参数、数据格式、通信协议等。

b) 接口设计原则

1) 模块化：将接口设计成独立的模块，便于维护和升级。

2) 标准化：遵循统一的标准和规范，提高系统的兼容性和互操作性。

3) 可扩展性：考虑到未来技术的发展，设计时应预留扩展接口和升级空间。

4) 安全性：确保接口设计符合安全要求，防止数据泄露和系统被非法控制。

c) 详细接口规范

1) 数据接口

传感器数据接口：定义传感器数据的格式、传输协议、实时性要求等。

融合数据接口：描述融合算法的输出数据格式和接口标准。

2) 控制接口

执行器控制接口：定义控制执行器的指令格式、响应时间等。

决策控制接口：描述决策模块如何接收输入数据并发出控制指令。

3) 通信接口

内部通信接口：定义系统内部各模块之间的通信协议和接口标准。

外部通信接口：描述硬件系统与外部设备（如云端服务器、其他车辆等）的通信方式和接口标准。

d) 测试和验证

1) 接口测试：编写测试用例，对接口进行功能和性能测试，确保接口符合规范要求。

2) 系统集成测试：将各模块通过接口连接起来，进行系统集成测试，验证系统整体性能。

e) 文档编写

1) 接口规范文档：详细记录接口的定义、功能、设计原则、测试方法等。

2) 用户手册：为开发人员和使用人员提供操作指南和注意事项。

f) 更新和维护

1) 定期更新：随着技术的发展和标准的更新，定期修订接口规范。

2) 反馈机制：建立用户反馈机制，收集使用过程中发现的问题和建议，用于规范的改进和优化。

7 硬件设计

7.1 硬件设计概述

智能车辆驾驶系统中的硬件设计是一个高度集成且相互协作的生态系统，涵盖了感知系统、计算与处理单元、执行系统、通信与数据传输系统以及安全与冗余系统等多个方面。

本章的目的是：

a) 创建一个硬件设计 ( 请参阅第 7.2 章节 )

1) 支持以安全为导向的分析

2) 考虑安全导向分析的结果符合硬件安全要求

3) 符合软硬件接口规范

4) 符合系统架构设计规范

5) 满足所需的硬件设计特性

b) 对设计的硬件架构进行验证 ( 请参阅第 7.3 章节 )

1) 硬件设计能满足硬件安全要求和软硬件接口规范

2) 假设的有效性 , 此假设用于开发集成在已开发硬件中的每 SEooC:

3) 安全相关的特殊特性的适用性 , 以实现生产和服务期间的功能安全。

c) 定义在生产、运行、服务和报废期间的硬件安全要求并提供有关信息 ( 详情见第 7.4 章节 )

7.2 硬件架构设计

7.2.1 硬件架构除了应实现第 6 章定义的硬件安全要求外，还应对 ASIL 等级中，涉及与安全管理有关的等级 (A 、 B 、 C 、 D) 进行要求的分解，这包括：

a) 硬件安全要求应分配到对应的硬件要素 , 每个硬件要素都应按照分配给它的所有要求中最高的 ASI1 等级来开发。

注 1: 硬件要素的各个特征将继承该要素所实现的硬件安全要求中最高的 ASIL 等级。

b) 如果在硬件架构设计中对硬件安全要求应用了 ASIL 等级分解 ,ASIL, 等级分解应按照 GB3/T34590.9-2022 第 5 章的要求进行。

c) 如果一个硬件要素是由 ASIL, 等级低于要素 ASIL, 等级或没有指定 ASI1, 等级的子要素组成。除非满足按照 GB/T34590,9-2022 第 6 章的共存准则 , 否则应按照最高的 ASIL 等级处理每个子要素。

d) 对于与信息安全有关的存储数据硬件应按照高风险值的可行性等级较高的攻击路径进行符合风险处理方案的设计防护。

e) 对于暴露场景或者工作运行环境有严格要求的硬件组件，但并未指定 ASIL 等级的，应按照最高 ASIL 等级的硬件安全要求进行。

7.2.2 对硬件安全要求和硬件架构设计要素之间的可追潮性 , 应保持到硬件组件的最底层。

注 : 硬件安全要求的可追溯性不要求深入到硬件详细设计，对于不能划分为子元器件的硬件元器件 , 不分配硬件安全要求。

示例 1 ：试图建立每个电容和电阻等硬件的可追性既没有意义 , 也没有益处。

为避免系统性故障 , 应通过使用表 1 中列出的原则 , 使硬件架构设计具有下述特性 :

a) 模块化

注 1: 模块化使得硬件要素的设计无需修改就可以重复使用 ( 如温度探测电路模块、微控制器中的 ECC 模块 )

b) 适当的粒度水平

注 2: 其目的是架构在必要的详细程度上体现必要的信息 , 来显示安全机制的有效性 . 简单性。

c) 简单性

d) 实时性

智能驾驶系统对实时性要求很高，硬件系统的设计必须能够满足算法的实时运行需求。选择高性能的处理器和通信接口，优化算法的执行效率，减少系统延迟。

e) 电磁兼容性

硬件系统中的电子设备会产生电磁干扰，可能影响其他车载设备的正常运行。进行电磁兼容性设计，包括屏蔽、滤波和接地等措施，确保硬件系统与其他车载设备的兼容性。

表 3 硬件架构设计原则

原则		ASIL 等级
原则		A	B	C	D
1	分层设计	＋	＋	＋	＋
2	安全相关硬件组件的精确定义接口	＋＋	＋＋	＋＋	＋＋
3	避免不必要的接口复杂性	＋	＋	＋	＋
4	避免不必要的硬件组件复杂性	＋	＋	＋	＋
5	可维护性 ( 服务 )	＋	＋	＋＋	＋＋
6	可测试性	＋	＋	＋＋	＋＋
可测试性包括开发、生产、服务和运行过程中的测试。

7.2.3 在硬件架构设计时 , 应考虑安全相关硬件组件失效的非功能性原因。

如果适用 , 可包括以下的影响因素 : 温度、振动、水、灰尘 , 电干扰 , 噪声因素或来自硬件架构的其他硬件组件或其所在环境的串扰。

7.2.4 在硬件架构设计时 , 应考虑安全相关硬件组件失效的网络信息原因。

如果存在可能风险 , 可包括以下的影响因素 : 安全密码泄露、物理接口损坏、云端服务器攻击因素或来自硬件架构的其他硬件组件或其搭载的软件被侵入的干扰。

7.3 硬件详细设计

7.3.1 为了避免常见的设计缺陷 , 应从其他相关项安全生命周期的执行过程中学习经验，经验来源包括：

a) 相关行业标准

示例 1 ：国际汽车工程师学会（ SAE ）要求 L3 级及以上的智能驾驶需要具备冗余的传感器和计算单元，以确保系统在出现故障时仍能安全运行。

b) 学术研究成果

c) 企业实践经验

d) 项目实践与测试

e) 行业专家与咨询机构

通过对上述来源的经验进行总结，将获得的改进应用于后续的相关项，组织应建立、执行并维护持续改进的流程，图 1 提供了一个初步的流程架构。

$C:\Users\sys002\Desktop\底盘综合控制-一汽\七月份硬件开发融合规范\硬件详细设计流程图.jpg$ 图 7.1 硬件设计持续改进流程图

7.3.2 在硬件架构设计时 , 应考虑安全相关硬件组件失效的非功能性原因。

如果适用 , 可包括以下的影响因素 : 温度、振动、水、灰尘 , 电干扰 , 噪声因素或来自硬件架构的其他硬件组件或其所在环境的串扰。

7.3.3 在硬件架构设计时 , 应考虑安全相关硬件组件失效的网络信息原因。

7.3.4 按照硬件详细设计 , 应考虑硬件元器件或硬件组件的任务剖面和运行条件。

确保硬件元器件或硬件组件在其规格范围内运行 , 以避免其由于逾期使用而发生失效。

注 1 ：除功能要求所应满足的任务要求之外，还应考虑 “ 车 - 路 - 云 ” 系统硬件部分在任务剖面中所承担的数据采集、传输、处理、分析和控制等重要任务。

7.3.5 宜考虑鲁棒性设计原则。

车辆硬件的鲁棒性设计原则主要体现在以下几个方面：

a) 冗余设计

示例 1 ：国际汽车工程师学会（ SAE ）要求 L3 级及以上的智能驾驶需要具备冗余的传感器和计算单元，以确保系统在出现故障时仍能安全运行。

b) 耐候性与环境适应性

c) 部件耐用性

d) 模块化设计 - 降低车辆耦合性

注 1: 鲁棒性设计原则可以通过硬件设计指南的应用来体现。

示例 1 : 关于组件应对环境和运行应力因素鲁棒性的保守规范

7.4 硬件安全分析

7.4.1 硬件设计的安全分析 , 应按照表 4 进行 , 以识别失效的原因和故障的影响。

注 1: 安全分析的最初目的是支持硬件设计的定义 , 其后 , 安全分析能用于硬件设计验证。

注 2: 就安全分析支持硬件设计定义的目的来说 , 定性分析可能是适当且充分的。

表 4 硬件设计安全分析

方法		ASIL 等级
方法		A	B	C	D
1	演绎分析	o	＋	＋＋	＋＋
2	归纳分析	＋＋	＋＋	＋＋	＋＋
注：分析的详细程度与设计的详细程度相对应。在某些情况下 , 两种方法都可在不同的细节层面上执行。示例 : FMEA 是在硬件组件层面上完成的 , 提供了在更高抽象层面上执行的 FTA 的基本事件。

7.4.2 本要求适用于等级为 ASI1(B) 、 C 和 D 的安全目标。对于每个安全相关的硬件组件或元器件 , 针对所考虑的安全目标 , 安全分析应识别以下内容 :

a) 安全故障

b) 单点故障或残余故障

c) 多点故障 ( 无论是可感知的、可探测的或潜伏的 )

d) 非功能性故障

e) 信息故障

注 1: 识别多点故障的目的 , 并不要求对每一种可能的两个硬件故障的组合进行系统的分析 , 但至少要考虑从技术安全概念得出的组合。

示例 1 ：一个故障影响了安全相关的要素 , 另一个故障影响了相应的为达到或维持安全状态所需的安全机制。

注 2: 在大多数情况下 , 分析可能限制到双点故障。但有时阶次高于 2 的多点故障可能显示与技术安全概念有关。

示例 1 ：当执行冗余安全机制时。

7.4.3 本要求适用于等级为 ASIL(A) 、 (B) 、 (C) 和 (D) 的安全目标。应具备实施的安全机制对防止导致单点失效的故障或减少残余故障的有效性的证据。

为了这个目的 :

a) 应具备证据以证明安全机制具有实现和保持安全状态的能力 ( 特别是在容错时间间隔和最大故障处理时间间隔内适当的失效减轻能力 ) 。

b) 应评估由安全机制实现的残余故障的诊断覆盖率。

注 1: 一个可能在任何时问 ( 例如 , 不仅在上电时 ) 发生的故障 , 如果故障探测时间间隔加上相应安全机制的故障响应时间 , 大于相应的容错时间间隔或指定的最大故障处理时间间隔 , 则不能认为此故障被有效覆盖。

注 2: 如果能证明某一特定故障模式可能仅发生在上电时 , 并且在车辆行驶期间发生的概率是可以忽略的 , 那么对这些故障仅在上电后执行启动测试是可以接受的。

注 3: 能用例如 FMEA 或 FTA 分析来构建理由

注 4: 根据对硬件要素失效模式和它们对更高层面的影响的认知 , 这种评估可能是硬件要素的整体诊断覆盖率 , 或更详细的失效模式的覆盖率评估。

注 5: 本要求适用于硬件 , 软件或两者结合实现的安全机制。

7.4.4 本要求适用于等级为 ASIL 和 D 的安全目标。应具备实施的安全机制对防止潜伏故障的有效性的证据。

为了这个目的 :

a) 应具备证据以证明安全机制在可接受的多点故障探测时间间隔内完成潜伏故障的失效探测和实现或保持安全状态及警示驾驶员的能力 , 以确定哪些故障保持潜伏 , 哪些故障可被探测到。

b) 应评估由安全机制实现的潜伏故障的诊断覆盖率。

注 1 ：如果一个相应安全机制的故障处理时间间隔大于相应的潜伏故障的多点故障探测时间间隔 , 则不能认为此故障被有效覆盖。

注 2: 能用例如 FMEA 或 FTA 分析米构建理由。

注 3: 根据对硬件要素失效模式和它们对更高层面的影响的认知 , 这种评估可能是硬件要素的全局诊断覆盖率 , 或更详细的失效模式的覆盖率评估。

注 4: 本要求适用于硬件、软件或两者结合实现的安全机制。

7.4.5 如果适用 , 应按照 G/T34590.9-2022 第 7 章进行相关失效分析 , 提供证据证明设计中的硬件要素与它们的独立性要求相符合。

注 1: 见 G B /T34590.9-2022 附录 C

注 2: 见 GB/T34590.11-2022 中 4.7

7.4.6 如果硬件设计引入了新危害 , 且这个危害没有被现有的 HARA 报告覆盖 , 则应按照 GB/T34590,8-2022 第 8 章中的变更管理流程对它们进行引人和评估。

注 : 新识别出的 , 没有被现有安全目标覆盖的危害 , 通常是非功能性的危害。非功能性的危害在 GB/T 34590 范围之外 , 但在危害分析和风险评估中能对它们添加如下注释 ,“ 由于不在 GB/T3450 的范围内 , 所以没有对该危害指定 ASI 等级 ” 。然而 , 也能指定一个 ASIL 等级作参考。

7.5 硬件设计验证

7.5.1 应按照表 3 中列出的硬件设计验证方法提供证据证明 :

a) 满足硬件安全要求

b) 与软硬件接口规范兼容

c) 用来在生产和服务过程中实现功能安全的安全相关特殊特性的适用性

表 5 硬件设计验证

方法		ASIL 等级
方法		A	B	C	D
1a	硬件设计走查 a	＋＋	＋＋	●	●
1b	硬件设计检查 a	＋	＋	＋＋	＋＋
2	安全分析	按照 7.4.3
3a	仿真 b	o	＋	＋	＋
3b	通过硬件原型开发 b	o	＋	＋	＋
注 : 该验证评审的范围是与硬件安全要求相关的技术正确性和完整性。
a 方法 1a 和 1b 检查硬件设计中硬件安全要求是否得到完整和正确的执行。 b 当认为分析方法 1 和 2 不充分时 , 利用方法 3a 和 3b 检查硬件设计的特定点示例： GB/T34590.11-2022 中 4.8 所述的故障注入。

7.5.2 方法 1a 和 16 检查硬件设计中硬件安全要求是否得到完整和正确的执行。

在硬件设计过程中 , 如果发现任何硬件安全要求的实施是不可行的 , 应按照变更流程提出变更请求。

7.5.3 应根据硬件安全要求和硬件设计规范验证用于开发集成到硬件中的 SEooC( 独立于环境的安全要素 ) 的假设的有效性。

7.6 生产、运行、服务和报废

7.6.1 如果安全分析表明安全相关的特殊特性与生产、运行、服务和报废相关 , 则应定义这些安全相关的特殊特性。

安全相关的特殊特性的定义应包括 :

a) 生产和运行的验证措施。

b) 这些措施的接受准则。

示例 : 对一种依赖于新的传感器技术的硬件设计的安全分析 ( 例如 , 摄像头或雷达传感器 ), 能揭示出这些传感器与特殊安装流程的关系。这种情况下 , 在生产阶段对这些组件的额外验证措施可能是必要的。

7.6.2 如果安全相关硬件要素的错误组装 , 拆卸和报废可能对实现或维护功能安全产生不利影响 , 则应该将避免错误执行所需的信息告知按照 GB/T 34590.2-2022 第 7 章委任的负责生产、运行、服务和报废的人员。

7.6.3 按照 GB/T 34590.7-2022 中的 5.4.1.2 和 5.4.3.3, 安全相关硬件要素应可追潮。

其目的是 :

a) 启用召回或更换管理。

注 : 这可能包括适当的标签或其他的硬件要素识別方法 , 来表示它们是与安全相关的。

7.6.4 如果错误的服务可能对实现或维护功能安全产生不利影响 , 则应该将避免此类影响执行所需的信息告知负责生产 , 运行、服务和报废的人员。

7.6.5 硬件设计过程中产生的硬件要素的生产、运行、服务和报废要求 , 应告知按照 GB/T 34590.2-2022 第 7 章委任的负责生产、运行、服务和报废的人员。

8 硬件架构度量评估

8.1 硬件架构度量评估概述

本章的目的是提供基于硬件架构度量的证据 , 来证明相关项硬件架构设计在安全相关的随机硬件失效探测和控制方面的适用性。

本章描述了两种硬件架构的度量 , 用于评估相关项架构应对随机硬件失效的有效性。

这些度量和关联的目标值在相关项层面对相关项的硬件要素进行评估 , 并与第 9 章描述的对随机硬件失效导致违背安全目标的评估互为补充。

这些度量所针对的随机硬件失效仅限于相关项中某些安全相关电子和电气硬件元器件 , 即那些能对安全目标的违背或实现有显著影响的元器件 , 并限于这些元器件的单点故障、残余故障和潜伏故障。对于机电硬件元器件 , 则仅考虑电气失效模式和失效率。

注 1: 计算中能忽略阶次高于 2 的多点故障硬件要素 , 除非它们与技术安全概念相关。

硬件架构度量能在硬件架构设计和硬件详细设计过程中迭代使用。

硬件架构度量取决于相关项的整体硬件。对相关项涉及的每个安全目标 , 都应符合规定的硬件架构度量的目标值。

定义这些硬件架构度量以实现下列目标 :

a) 客观上可评估 : 度量是用来区分不同的架构的一种可理解的手段 ;

b) 支持最终设计的评估 ( 即基于选取的详细的硬件设计完成计算 );

c) 为评估硬件架构的充分性而提供基于 ASIL 等级的通过 / 未通过准则 ;

d) 显示用于防止硬件架构中单点或残余故障风险的安全机制的覆盖率是否足够 ( 单点故障度量 );

e) 显示用于防止硬件架构中潜伏故障风险的安全机制的覆盖率是否足够 ( 潜伏故障度量 );

f) 处理单点故障、残余故障和潜伏故障 ;

g) 考虑到硬件失效率的不确定性 , 确保硬件架构的鲁棒性 :

h) 仅限于安全相关要素 :

i) 支持不同要素层面的应用 , 例如 , 能为供应商的硬件要分配目标值

示例 : 为方便分布式开发 , 能为集成电路或者 ECU 分配导出的目标值。

注 2: 具有安全相关可用性要求的相关项 ( 即失去某一功能可能导致危害事件 ) 与不具有安全相关可用性要求的相关项一样 , 受相同硬件架构度最的要求和目标的约束。

硬件架构度量（ Hardware Architecture Metric, HAM ）：用于评估硬件架构对解决违背安全目标故障的有效性。这包括确定硬件失效是否会违背安全目标、硬件失效的总失效率、安全机制的监控或控制覆盖率等。

8.2 硬件指标评估基础

8.2.1 本要求适用于等级为 ASIL(B),(C) 和 (D) 的安全目标。

应将按照诊断覆盖率、单点故障度量和潜伏故障度量的概念用于此要求。

8.2.2 本要求适用于等级为 ASIL(B) 、 (C) 和 (D) 的安全目标。

应结合残余故障和相关的潜伏故障来预估安全机制所实现的安全相关硬件要素的诊断覆盖率。

注 1: 附录 D 可以作为起始点 , 为已制定的安全机制确定诊断覆盖率。所声明的诊断覆盖峯需要合适的理由支持。

注 2: 根据对硬件要素失效模式和它们对更高层面影响的认知 , 这种评估可能是一个硬件要素的诊断覆盖常评估或更详细的失效模式的覆盖率评估。

8.2.3 本要求适用于等级为 ASI(B) 、 (C) 和 (D) 的安全目标。分析中用到的硬件元器件预估失效率的确定 , 应使用以下方法 :

a) 使用业界公认的硬件元器件失效率数据

示例 1: 用于确定硬件元器件失效率和失效模式分布的业界公认的来源包括 SN 29500 、 IEC 61709 、 MILHDBK 217 F notice 2,RIAC HDBK 217 Plus ,UTE C80-811,NPRD-2016,EN 50129:2003 Annex C,RIACFMD-2016 、 MIL,HDBK 338 和 FIDES guide 2009 EdA 。例如 , 能使用由 “Alessandro Birolini- 可靠性工程 ” 定义的失效模式分布。

注 1: 这些数据库给出的失效率数据一般都比较保守。

注 2: 在应用选定的业界数据源时 , 为避免人为降低所计算出的基础失效率 , 考虑以下因素 :

1) 任务剖面 ;

2) 失效模式相对于运行条件的适用性 :

3) 失效率单位 ( 每工作小时或每日历小时 ) 。

b) 使用现场反馈的统计数据。这种情况下 , 预估的失效率宜有至少 70% 的可比置信度

注 3: 如果 SPFM 和 LFM 评估中使用的不同硬件元器件的故障率的置信度显著不同 , 则度量指标将是有偏差的。

注 4: 在将这些从现场反馈的基于统计的数据与不同置信度的其他数据源的值放在一起使用之前 , 可能仍然需要衡量这些数据。也可见注 7 。

注 5: 基于现场反馈的失效率能按照 GB/T 34590.8-2022 第 14 章 ( 在用证明 ) 的描述进行计算。

c) 使用工程方法形成的专家判断 , 该工程方法基于定量和定性的论证。应按照结构化准则进行专家判断 , 这些准则是判断的基础 , 应在失效率预估前进行设定。

注 6: 考虑到设计的新颖性 , 专家判断的准则可能包括由现场数据、测试 , 可靠性分析和基于物理失效仿真方法的启发式信息组合。

注 7: 能使用国际可靠性专家机构提供的资料 :SAE J1211“ 鲁棒性验证 ” 分析、建模和仿真提供了基于物理失效 (PoF) 的失效机制模型、 JEDEC-JESD89 、 JEDEC-IESD91,JEDEC-JESD94 、 JEDEC-JEP143 和 JEDEC-JESD148 。

注 8: 如果失效率来自多个数据源 ( 如在 8.4.3 列举的 ) 结合 , 例如 , 如果不同部件的失效率不能从同一来源获得 , 则能使用比例系数来缩放失效率 , 以便不同失效率的预测质量相等。如果可获得两个失效率源之间的比例系数的原理 , 则能使用这种比例。

示例 2: 只在一个数据源中发现要素失效率 , 而类似的要素在该源和另一个源中可用。比例系数是使用相同任务剖面的两个来源的失效率之比。

示例 3: 数据手册的失效率通常被认为是保守的。如果已选择与使用手册数据一致的随机硬件失效目标值。则能通过应用适当的比例系数 , 使用从现场反馈的失效率 ( 例如 , 对应于比通常更保守的置信度 ) 。

注 9: 如果没有合适的比例系数 , 则能将符合 SPFM 和 LFM 要求的单独目标值分配给所考虑的不同要素 ( 类似于 8.4.4) 。

8.3 硬件指标评估要求

硬件随机失效概率度量（ Probabilistic Metric of Random Hardware Failures, PMHF ）：用于评估硬件随机故障导致违背安全目标的残余风险。这涉及到计算单点故障、残余故障和潜伏故障的失效率，并与 ASIL 等级的要求进行比较。

8.3.1 本要求适用于等级为 ASI(B),C 和 D 的安全目标，如果能够提供的硬件元器件失效率证据不足 , 应提出替代方案。

示例：增加安全机制来探测和控制此故障。

如果替代方法仅包括附加的以下安全机制 :

a) 硬件元器件残余故障的诊断覆盖率应等于或高于相关项 SPFM 目标值 ;

b) 硬件元器件潜伏故障的诊断覆盖率应等于或高于相关项 IFM 目标值。

注 1: 例如 , 充分的证据可以指失效率是通过 8.4.3 中列出的方法得到的。

注 2: 在确定安全机制的覆盖率时 , 能考虑硬件元器件的安全故障比例。在这种情况下 , 覆盖率的计算与单点故障度量或潜伏故障度量的计算方法类似 , 都是在硬件元器件层面而不是在相关项层面进行的。

8.3.2 本要求适用于等级为 ASI(B),C 和 D 的安全目标。对于每一个安全目标 , 由 “ 单点故障度量 (SPFM)” 的定量目标值应基于下列参考目标值来源之一 :

a) 自应用于值得信赖的相似设计中 , 对硬件架构度量的计算

注 1: 两个相似的设计有相似的功能和分配了相同 ASIL 等级的相似安全目标。

b) 自表 4 。

表 6 “ 单点故障度量 ” 目标值的可能推导来源

	ASIL B	ASIL C	ASIL D
单点故障度量	≥90%	≥97%	≥99%

注 2: 此定量目标的目的是提供 :

a) 设计指南 ;

b) 设计符合安全目标的证据

8.3.3 本要求适用于等级为 ASI(B),C 和 D 的安全目标。对于每一个安全目标 , 由的潜伏故障度量 (LFM) 的定量目标值应基于下列参考目标值来源之一 :

a) 来自应用于值得信赖的相似设计中，对硬件架构度量的计算。

注 1: 两个相似的设计有相似的功能和分配了相同 ASIL 等级的相似安全目标。

b) 自表 6 。

表 6 “ 潜伏故障度量 ” 目标值的可能推导来源

	ASIL B	ASIL C	ASIL D
单点故障度量	≥60%	≥80%	≥90%

注 2: 此定量目标的目的是提供 :

a ) 设计指南 ;

b ) 设计符合安全目标的证据

8.4 硬件指标 LFM 与 SPFM 的评估方法

8.4.1 本要求适用于等级为 ASI1 (B),(C) 和 (D) 的安全目标 , 对于每个安全目标 , 相关项的整体硬件应符合下列两者之一 :

a) 满足 8.3.1 中描述的 “ 单点故障度量 ” 目标值 .

b) 满足在硬件要素层面规定的合适目标 , 这些目标足以符合分配给相关项整体硬件的单点故障度量的目标值 ( 如 8.4.5 中所描述的 ), 并提供理由说明在硬件要素层面符合这些目标。

注 1: 如果相关项包含失效率等级有显著差异的不同种类的硬件要素 , 就会存在这样的风险 , 即为了满足硬件架构度量时仅关注具有最高等级失效率的那些硬件要素。一个可能发生此情况的例子是 : 只考虑线束保险丝或接插件的失效率 , 而忽略失效率显著较低的硬件元器件的失效率 , 就以为实现了对单点故障度量的符合性。为每一类硬件规定合适的度量目标有助于规避这种不良影响，

注 2: 当瞬态故障与所用技术相关时 , 要考虑这些态故障 , 能通过给它们指定并确认一个特定的单点故障度量目标值 ( 如注 1 中解释的 ), 或通过一个基于对内部安全机制有效性验证的定性理由来处理这类瞬态故障。

注 3: 如果不满足目标 , 将按 4.2 所述评估如何实现安全目标的理由。

注 4: 能结合考虑多个或所有适用的安全目标来确定单点故障度量 : 但在这种情况下 , 采用最高 ASI, 等级的安全目标的度量目标。

示例 : 如果一个相关项由三个硬件要素 A 、 B 和 C 组成 , 失效率分别为 𝛌 A , 𝛌 B 和 𝛌 C , 且则满足以下公式要素 SPFM 目标值的元素的任意组合是可接受的 :

8.4.2 本要求适用于等级为 ASIL(B) 、 (C) 和 (D) 的安全日标。对于每个安全目标 , 相关项的整体硬件应该符合下列之一 :

a) 满足 8.3.2 中描述的 “ 潜伏故障度量 ” 目标值 .

b) 满足在硬件要素层面规定的合适目标 , 这些目标足以符合分配给相关项整体硬件的潜伏故障度量的目标值 ( 在 8.3.2 中给出 ), 并有理由说明在硬件要素层面符合这些目标。

c) 对于其故障可能导致安全机制 ( 防止故障违背安全目标 ) 无效的每个硬件要素 , 满足相关潜伏故障的诊断覆盖率目标值 , 该值与 8.3.2 中给出的潜伏故障度量目标值一致 ( 被当作诊断覆盖率 ), 当每个安全机制都是基于故障探测且其无效可能导致违背安全目标时 , 适用此选项。

注 1: 列项 c) 仅限于在每个相关项安全机制是基于故障探测的情况。在此情况下 , 通过这些安全机制的探测来警示目标功能的可能潜伏故障。在其他情况下 , 则只有选项 a) 和 b) 适用。

示例 1: 附录 A 提供了考虑潜伏故障处理的不同类型安全机制的示例。

注 2: 在列项 c) 情况下 , 不计算度量 , 只评估安全机制对于硬件要素的潜伏故障的覆盖率。

注 3: 如果相关项包含失效率等级显著差异的不同种类的硬件要素 , 就会存在这样的风险 , 即为了满足硬件架构度量时仅考虑具有最高等级失效率的那些硬件要素。一个可能发生此情况的例子是 , 只考虑线束、保险丝或接插件的失效率 , 而忽略失效率显著较低的硬件元器件的失效率 , 就认为实现了对潜伏故障度量的符合性，为每一类硬件规定合适的度量目标值有助于规避这种不良影响。

注 4: 如果不满足目标 , 将按 4.2 所述评估如何实现安全目标的理由。

注 5: 可以结合考虑多个或所有适用的安全目标来确定潜在故障度量；但在这种情况下 , 采用最高 ASIL 等级的安全目标的度量目标。

示例 2: 如果一个相关项由三个硬件要素 A 、 B 和 C 组成 , 失效率分别为 𝛌 A , 𝛌 B 和 𝛌 C , 且则满足以下公式要素 LFM 目标值的元素的任意组合是可接受的 :

9 随机硬件失效导致违背安全目标的评估

9.1 随机硬件失效导致违背安全目标的评估概述

本章的目的是提供用于表明相关项随机硬件失效导致违背安全目标的残余风险足够低的证据注 :“ 足够低 ” 指 ” 与已经在使用并且已知安全的相关项的残余风险相当 ”

推荐用两个可选的方法 ( 见 9.4) 以评估违背安全目标的残余风险是否足够低。

两个方法都评估由单点故障、残余故障和可能的双点故障导致的违背安全目标的残余风险。如果显示为与安全概念相关 , 也能考虑多点故障。在分析中 , 对残余和双点故障 , 将考虑安全机制的覆盖率，并且 , 对双点故障也将考虑暴露持续时间。

9.4.2 给出第一条方法的要求。 “ 随机硬件失效概率度量 ”(PMHF) 代表一种评估硬件要素随机失效是否违背所考虑的安全目标的定量分析方法。这种定量分析结果会与目标值作对比。

9.4.3 给出第二条方法的要求。 “ 对违背安全目标的每个原因的评估 ”(EEC) 是基于对每个硬件元器件及其在单点失效 , 残余失效和合理的双点失效方面对违背所考虑的安全目标的影响的独立评估。

所选用的方法在硬件架构设计和硬件详细设计中能被迭代应用。

本章的范围限于相关项的随机硬件失效。分析中所考虑的是电子电气硬件元器件。对于机电硬件元器件 , 仅考虑电气失效模式和失效率。

9.2 随机硬件失效评估方法

9. 2 .1 本要求适用于等级为 ASIC 和 D 的安全目标。单一硬件元器件单点故障只有在提供有效论据证明其发生概率足够低时才能考虑接受 , 这些论据包括以下选项中的一个。

a) 采取专用措施 ; 或

b) 对于 ASI1.D 等级安全目标 , 需要满足以下准则：

—— 采用保守的数据来源；

—— 只有一小部分的失效率能够违背安全目标 ( 例如 , 一个特殊的失效模式 ) ；

—— 得出的单点故障失效率小于失效率等级 1 对应失效率的十分之一。

c) 对于 ASILC 等级安全目标 , 需要满足以下准则：

—— 采用保守的数据来源；

—— 只有一小部分的失效率能够违背安全目标 ( 例如 , 一个特殊的失效模式 ) ；

—— 得出的单点故障失效率小于失效率等级 2 对应失效率的十分之一。

注 1: 针对本条要求 , 微控制器、专用集成电路 (ASIC) 或相似的片上系统 (SoC) 均能看作硬件元器件。

注 2: 专用措施可能包括 :

a) 设计特征 , 如硬件元器件过设计 ( 例如 , 电气或热应力等级 ) 或者物理隔离 ( 例如 , 印刷电路板上的触点间隔 ) ；

b) 专门的来料抽样测试 , 以降低此失效模式发生的风险； :

c) 老化测试；

d) 作为控制计划一部分的专用控制设备；

e) 安全相关的特殊特性的分配。

9.2.1 本要求适用于等级为 ASILC 和 D 的安全目标。如果一个硬件元器件的残余故障诊断覆盖率低于 90%, 只有在提供有效论据证明其发生概率足够低时才能考虑接受 , 这些论据包括以下选项中的一个。

a) 采取专用措施 (9.4.1.2 中注 2 列举的专用措施示例 ) 。

b) 对于 ASII,D 等级安全目标 , 需要满足以下准则：

—— 采用保守的数据来源；

—— 只有一小部分的失效率能够违背安全目标 ( 例如 , 一个特殊的失效模式 ) ；

—— 得出的残余故障失效率小于失效率等级 1 对应失效率的十分之一。

c) 对于 ASI1C 等级安全目标 , 需要满足以下准则：

—— 采用保守的数据来源；

—— 只有一小部分的失效率能够违背安全目标 ( 例如 , 一个特殊的失效模式 ) ；

—— 得出的残余故障失效率小于失效率等级 2 对应失效率的十分之一。

注 1: 针对本条要求 , 能把一个微控制器、一个专用集成电路或相似的片上系统看作硬件元器件。

注 2: 当确定安全机制的覆盖率时 , 能考虑硬件元器件安全故障的比例。在这种情况下 , 覆盖率的计算与单点故障度量的计算类似 , 但仅在硬件元器件层面 , 而不在相关项层面。

9.3 随机硬件失效概率度量 (PMHF) 的评估

9.3.1 本要求适用于等级为 ASII(B),(C) 和 (D) 的安全目标。

9.4.3.2 或 9.4.3.3 要求的定量目标值应表述为相关项整个运行生命周期中每小时的平均概率。

注 1: 即使共用相同单位 , 失效率和相关项整个运行生命周期中每小时的平均失效概率是不同的值。

注 2: 运行生命周期仅包括实际工作时间。

9.3.2 本要求适用于等级为 ASIL(B),(C) 和 (D) 的安全目标。为随机硬件失效在相关项层面导致违背每个安全目标的最大可能性定义定量目标值 , 使用来源 a) 、 b) 或 c) 的参考目标值 , 如下所列 :

a) 来自表 6 。

b) 来自值得信赖的相似设计的现场数据。

c) 来自应用于值得信赖的相似设计中的定量分析技术

注 1: 这些来源于 a),b) 或 c) 的定量目标值没有任何绝对的意义 , 仅有助于将一个新的设计与已有设计相比较。其目的是生成可用的设计指导 , 并获得设计符合安全目标的可用证据。

注 2: 两个相似的设计拥有相似的功能和分配了相同 ASIL 等级的相似安全目标。

注 3: 在没有其他来源的情况下 , 通常使用表 6 确定随机硬件失效的目标值。

注 4: 表 6 中的适用于单一系统构成的相关项 ( 例如 , 发动机控制系统、电子稳定性控制系统、电动助力转向系统气囊约束系统 ) 。

注 5: 表 7 中的目标值与手册的数据是保持一致的 , 是保守的。如果对由于随机硬件失效导致违背安全目标的评估是基于统计数据的 ( 例如 , 来自现场数据 ), 则能修改表 6 中给出的目标值 , 以避免为实现目标值而产生人为简化。

表 7 得出随机硬件失效目标值的可能来源

ASIL 等级	随机硬件失效目标值
D	＜ 10 -8 h -1
C	＜ 10 -7 h -1
B	＜ 10 -7 h -1
注 : 此表中描述的定量目标值能按照 4.2 的规定进行剪裁以适应相关项的特定使用 ( 例如 , 若相关项能在比一部乘用车典型使用时间更久的持续时间内才违背安全目标 )

9.3.3 本要求适用于等级为 ASIL(B),(C) 和 (D) 的安全目标。当一个相关项由多个系统构成时 , 根据 9.3.2 要求得出的目标值可以直接分配给构成该相关项的每一个系统。只要这些系统中的每一个都有可能违背相同的安全目标，并且相应的相关项目标值不会增加超过一个数量级 , 就可以应用此方法。

注 1: 9.3.3 中所规定要求的可能性 , 例如 , 能用于新的更高级别功能所涉及的原有系统 ( 例如 , 新的 ADAS 功能所使用的发动机管理系统、电子稳定性控制系统、电动助力转向系统或气囊约束系统 ), 并且这些系统在以前的开发中达到了同样的安全目标。

示例 : 如果一个等级为 ASIL D 的安全目标分配给由多个系统 ( 最多 10 个 ) 组成的相关项 , 其中每个系统都有可能违背该安全目标 , 则能将目标值 10 -8 h -1 分配给组成该相关项的每个系统。

9.3.4 本要求适用于等级为 ASI(B),(C) 和 (D) 的安全目标。针对单点 , 残余和多点故障的硬件架构定量分析 , 应提供证据证明 9.3.2 或 9.3.3 要求的目标值已达到。此定量分析应考虑 :

a) 相关项的架构

b) 每个可导致单点故障或残余故障的硬件元器件的失效模式的估算失效率

c) 每个可导致多点故障的硬件元器件的失效模式的估算失效率

d) 安全机制对安全相关的硬件要素的诊断覆盖率 :

e) 多点故障情况下的暴露持续时间

注 1: 在定量分析中 , 考虑可能导致一个安全相关的硬件要素及其安全机制同时失效的硬件要素失效模式。它们可能是单点故障、残余故障或多点故障。

注 2: 暴露持续时间从故障可能发生时开始 , 包括 :

a) 与每个安全机制有关的多点故障探测时间间隔 , 或者当故障不对驾驶员显示 ( 潜伏故障 ) 时的车辆生命周期 :

b) 单次行程的最长持续时间 ( 对于驾驶员被要求以一种安全方式停车的情况 )

c) 直到车辆进入车间维修前的平均时间间隔 ( 对于驾驶员被警示要去维修车辆的情况 ) 。

因此 , 暴露持续时间取决于涉及的监控类型 ( 例如 , 连续监控、周期性自检、驾驶员监控、无监控 ) 和探测到故障后的反应种类。对于连续监控触发向安全状态转移的情况 , 它可能短至几毫秒。当没有监控时 , 它可能长到车辆的生命周期。

对车辆去维修的平均时间的假设示例 , 取决于故障的类型 :

a) 对舒适性功能的降级 ,200 次车辆行程

b) 对驾驶辅助功能的降级 ,50 次车辆行程

c) 对黄色警告灯或影响驾驶表现时 ,20 次车辆行程

d) 对红色警告灯 ,1 次车辆行程

通常不考虑维修所需要的时间 ( 除了评估能暴露给维护人员的危害 ) 。

一次车辆行程的平均时间间隔可能被认为等于 :

1) 乘用车为 1h 。

2) T &B 车辆为 10 h 。

注 3: 在大部分情况下 , 阶次高于二的多点失效对定量目标值的影响可以忽略。然而 , 在一些特定情况下 ( 极高的失效率或差的诊断覆盖率 ), 提供两个冗余的安全机制以达到目标可能是必要的。当技术安全概念是基于冗余的安全机制时 , 在分析中考虑阶次高于二的多点失效。

注 4: 如 9.3.2 注 1 中所指出的 ,PMHF 值不具有绝对意义 , 但对于比较新设计与现有设计是有用的。

注 5: 如果 9.3.2 或 9.3.3 中定义的目标值没有被满足 , 应按 4.2 对给出的如何实现安全目标的论据进行评估。这种论据可能基于 :

1) 识别影响 PMHF 值的主要因素和覆盖率较低的失效模式 :

2) 对这些因素进行评审 , 需考虑到其他准则的失效率 , 可靠性调查、诊断覆盖率 , 失效模式覆盖率、现场经验、验证措施、当前技术和专用措施 (9.4.1.2 中的注 2 列出了专用措施的示例 ) 。

注 6: 基于对硬件要素失效模式及其在更高层面上后果的认知 , 评估可能是硬件要素的诊断覆盖率 , 或者更详细失效模式覆盖率的评估。

注 7: 由于相关项 PMHF 值推导过程中的不确定性 ( 例如 , 失效率、失效模式 , 失效模式分布 , 诊断覆盖率 , 安全故障比例的推导 ), 计算值可能会有很大变化，解释时需特别注意。

9.4 对违背安全目标的每个原因的评估 (EEC)

9.4.1 对随机硬件失效导致违背安全目标的每个原因进行评估的方法 , 在图 8 和图 9 的流程图中子以了阐明。使用故障发生准则对每个单点故障进行评估。使用综合了故障发生和安全机制有效性的准则对每个残余故障进行评估。

$C:\Users\sys002\Documents\WeChat Files\wxid_q08yj2ozx37c22\FileStorage\Temp\1725177510676.png$

图 9.1 对单点故障和残余故障的评估流程

用于双点失效的流程在图 4 的流程图中进行了阐明。每个双点失效首先评估其可能性。如果两个故障同时导致的失效在足够短的时间内、以足够的覆盖率被探测或感知到 , 则认为这个双点失效不可能。如果双点失效是可能的 , 那么将使用综合了故障发生和安全机制覆盖率的准则对导致其发生的故障进行评估。

如果故障评估不满足故障发生和安全机制覆盖率的综合标准 , 则由故障导致的双点失效可能采用已有准则进行评估。

图 8 中描述的评估流程适用于硬件元器件 ( 电阻、电容、 CPU 等 ) 层面。

注 : 按照 9.3.4 的描述 , 通过定量分析技术 ( 例如 ,FTA 故障树分析 , 马尔科夫分析 ) 评估双点失效的发生率。

$C:\Users\sys002\Documents\WeChat Files\wxid_q08yj2ozx37c22\FileStorage\Temp\1725177554878.png$

图 9.2 对双点失效的评估流程

9.4.2 本要求适用于等级为 ASIL(B) 、 (C) 和 (D) 的安全目标。对违背所考虑的安全目标的每个单点故障、残余故障和双点失效进行单独的评估 , 应在硬件元器件层面执行。此评估应按照要求提供证据证明违背所考虑的安全目标的每个单点故障 , 残余故障和双点失效是可接受的。

注 1: 此分析能被看作是对割集的评审 , 覆盖率的缺失或不完整被当作是故障。

注 2: 在大部分情况下 , 阶次高于二的多点失效是可忽略的。然而 , 在一些特定情况 ( 极高的失效率或差的诊断覆盖率 ). 提供两个冗余的安全机制可能是必要的。因此 , 当技术安全概念是基于冗余的安全机制时 , 在分析中考虑阶次高于二的多点失效是必要的。

注 3: 当在子系统层面进行分析时 , 此分析能考虑在其他子系统中执行的系统安全机制。

注 4: 如果不能按照要求提供证据证明每个单点故障 , 残余故障和双点失效是可接受的 , 则按照 4.2 对满足该安全目标的合适理由进行评估。此理由能基于对这些故障 / 失效的评审 , 并考虑失效率、可算性调查、诊断覆盖率、失效模式覆盖率 , 现场经验 , 验证措施、当前技术 , 以及专用措施等其他标准 (9.4.2 注 2 给出了专用措施的示例 ) 。

9.4.3 本要求适用于等级为 ASIL(B) ， (C) 和 (D) 的安全目标。硬件元器件失效率的失效率等级评级应 9.4.3.3 按如下确定 :

注 1: 失效率等级 1 、 2 和 3 被引人以表示失效发生比率。这些等级分别与 FMEA 中使用的发生度水平 1 、 2 和 3 相似 , 即 1 分配给发生率最低的失效模式。

a) 失效率等级 1 对应的失效率应少于 ASIL D 等级的目标除以 100: 除非应用 9.4.4;

注 2: 能使用表 6 中给出的目标值。

b) 失效率等级 2 对应的失效率应小于或等于 10 倍的失效率等级 1 对应的失效率 ;

c) 失效率等级 3 对应的失效率应小于或等于 100 倍的失效率等级 1 对应的失效率 :

d) 失效率等级 i(i >3) 对应的失效率应少于或等于 10 (i-1) 倍的失效率等级 1 对应的失效率。

注 3: 失效率等级的分配是基于不考虑安全机制有效性的硬件元器件失效率。

注 4: 对于元器件中的少数 ( 如半导体器件的内部 ) 的失效率高于失效率等级 i 上极限的情况 , 如果分配了等级 i 后元器件的平均失效率低于失效率等级 i 的上极限 , 则这些元器件能被分配等级 i 。

9.4.4 本要求适用于等级为 ASIL(B),(C) 和 (D) 的安全目标。如果给出理由说明失效率等级评级可除以一个不等于 100 的数字。在此情况下 , 应确保在同时考虑单点故障 , 残余故障和更高程度的割集时。保持了正确的评级。

示例 : 理由能基于最小割集的数量或安全相关的硬件要素的数量。

9.4.5 本要求适用于等级为 ASIL(B),(C) 和 (D) 的安全目标。硬件元器件发生的单点故障应仅当相应的硬件元器件失效率等级符合表 7 给出的目标时 , 才被考虑接受。

表 8 针对单点故障的硬件元器件失效率等级目标

安全目标的 ASIL 等级	失效率等级
D	失效率等级 1 ＋专用措施 a
C	失效率等级 2 ＋专用措施 a 或失效率等级 1
B	失效率等级 2 或失效率等级 1
要求 9.4.1.2 的注 2 给出了专用措施的示例

注 : 当评估失效率等级时 , 能考虑硬件元器件的安全故障比例。

9.4.6 本要求适用于等级为 ASI(B) ， (C) 和 (D) 的安全目标。硬件元器件发生的残余故障应在失效率等级评级符合表 8 中为相应硬件元器件诊断覆盖率 ( 针对残余故障 ) 给出的目标时 , 被考虑接受。

注 1: 所考虑的失效率是硬件元器件失效率 , 不考虑安全机制的有效性。

表 9 对给定的硬件元器件 - 残余故障诊断覆盖率的最大失效率等级

安全目标的 ASIL 等级	针对残余故障的诊断覆盖率
安全目标的 ASIL 等级	≥99%	≥90%	≥90%	≤90%
D	失效率等级 4	失效率等级 3	失效率等级 2	失效率等级 1 ＋专用措施 a
C	失效率等级 5	失效率等级 4	失效率等级 3	失效率等级 2 ＋专用措施 a
B	失效率等级 5	失效率等级 5	失效率等级 5	失效率等级 2
要求 9.4.2 的注 2 给出了专用措施的示例

注 2: 表 8 定义了给定目标 ASIL 等级允许的最大失效率等级和诊断覆盖率之间的关联。更低的失效率等级是可接受的 , 但不要求。

注 3: “ 更低的失效率等级 ” 指带有更低数字的失效率等级。例如 , 针对失效率等级 3 的 “ 更低的失效率等级 ” 指失效率等级 2 和 1 。

注 4: 当确定安全机制的覆盖率时 , 能考虑硬件元器件安全故障的比例。在这种情况下 , 覆盖率的计算与单点故障度量的计算类似 , 但仅在硬件元器件层面 , 而不在相关项层面。

9.4.7 本要求适用于等级为 ASI1(B) 、 (C) 和 (D) 的安全目标。对失效率等级 i,i >3, 如果诊断覆盖率对于 ASIL D 等级大于或等于 [100- 10 (3-i) ]% , 或对于 ASIL B 和 C 等级大于或等于 [100- 10 (i-1) ]% , 则残余故障应被考虑接受。

注 1: 所考虑的失效率是硬件元器件失效率 , 不考虑安全机制的有效性。

注 2: 在确定安全机制的覆盖率时 , 能考虑硬件元器件安全故障的比例。在这种情况下 , 覆盖率的计算与单点故障度量的计算类似 , 但仅在硬件元器件层面，而不在相关项层面。

9.4.8 本要求适用于等级为 ASIL D 的安全目标。双点失效应被认为是可能的 , 如果 :

a) 涉及到的两个硬件元器件中至少有一个 , 其拥有的诊断覆盖率 ( 针对潜伏故障 ) 低于 90%

b) 引起双点失效的双点故障中的一个 , 保持潜伏的时间长于 6.4.8 中规定的多点故障探测时间间隔。

注 : 在确定安全机制的覆盖率时 , 能考虑硬件元器件安全故障的比例。在这种情况下 , 覆盖率的计算与潜伏故障度最的计算类似 , 但仅在硬件元器件层面 , 而不在相关项层面。

9.4.3.9 本要求适用于等级为 ASIL C 的安全目标。双点失效应被认为是可能的 , 如果 :

a) 涉及到的两个硬件元器件中至少有一个 , 其拥有的诊断覆盖率 ( 针对潜伏故障 ) 低于 80%

b) 引起双点失效的双点故障中的一个 , 保持潜伏的时间长于 6.4.8 中规定的多点故障探测时间间隔。

注 : 在确定安全机制的覆盖率时 , 能考硬件元器件安全故障的比例。在这种情况下 , 覆盖率的计算与潜伏故障度量的计算类似 , 但仅在硬件元器件层面，而不在相关项层面。

9.4.10 本要求适用于等级为 ASIL C 和 D 的安全目标。一个不可能的双点失效应被认为是与安全目标相符合的 , 因而是可接受的。

9.4.11 本要求适用于等级为 ASIL C 和 D 的安全目标。发生在硬件元器件中 , 并可能导致双点失效的双点故障 , 如果相应的硬件元器件符合表 9 中给出的失效率等级评级和诊断覆盖率 ( 针对潜伏故障 ) 的目标 , 应被认为是可接受的。

注 1: 所考虑的失效率是硬件元器件失效率。因此 , 不考虑安全机制的有效性。

表 10 关于双点故障的硬件元器件失效率等级和覆盖率的目标

安全目标的 ASIL 等级	针对潜伏故障的诊断覆盖率
安全目标的 ASIL 等级	≥99%	≥90%	≥90%
D	失效率等级 4	失效率等级 3	失效率等级 2
C	失效率等级 5	失效率等级 4	失效率等级 3

注 2: 表 9 定义了给定目标 ASIL 等级允许的最大失效率等级和能达到的诊断覆盖峯水平。更低的失效峯等级是可接受的 , 但不要求。

注 3: “ 更低的失效率等级 " 指带有更低数字的失效率等级。例如 , 针对失效率等级 3 的 “ 更低的失效率等级 ” 指失效辜等级 2 和 1 。

注 4: 在确定安全机制的覆盖率时 , 能考虑硬件元器件安全故障的比例。在这种情况下 , 覆盖率的计算与潜伏故障度量的计算类似 , 但仅在硬件元器件层面 , 而不在相关项层面。

注 5: 本要求同样适用于同一硬件元器件发生的可能导致双点失效的两个双点故障。

示例 : 安全机制 “ 奇偶校验 ” 存在于硬件元器件 “RAM" 中 , 因此 , 影响双点失效的双点故障 “RAM 单元故障和奇偶校验安全机制故障 " 都存在同一个硬件元器件 RAM 中。对于被视为可接受的两个双点故障 , 硬件部分 "RAM" 需要满足

10 硬件集成与验证

10.1 硬件集成与验证概述

硬件测试是验证智能驾驶车辆系统稳定性和可靠性的重要手段。通过全面而深入的测试，可以发现并解决潜在的问题，确保系统在各种场景下都能稳定运行。

本章的目的是：

确保开发硬件符合硬件安全要求。

10.2 硬件集成和测试活动

10.2.1 硬件集

10.2.2 硬件集成和验证活动应当验证硬件安全要求实施的完整性和正确性。

为了达到这些目的 , 应考虑表 11 所列方法

表 11 验证硬件安全要求实施的完整性和正确性的硬件集成测试

方法		ASIL 等级
方法		A	B	C	D
1	功能测试 a	＋＋	＋＋	＋＋	＋＋
2	故障注入测试 b	＋	＋	＋＋	＋＋
3	电气测试 c	＋＋	＋＋	＋＋	＋＋
a 功能测试的目的是验证相关项的规范里定义的特性已经达到。将充分表征预期正常操作的数据输入到相关项 , 把它们的响应与规范里给定的响应做比较。对与规范不同的异常和规范不完整的迹象 , 应给予分析。 b 有关半导体组件故障注人的更多信息 , 见 GB/Tb34590.11-2022 中的 4.8 。 c 电气测试的目的是验证在规定的电压范围内 ( 静态的和动态的 ) 符合硬件安全要求。现有标准包括 ISO 16750 和 ISO 11452.

10.3 硬件集成测试用例生成方法

表 12 导出硬件集成测试用例的方法

方法		ASIL 等级
方法		A	B	C	D
1a	需求分析	＋＋	＋＋	＋＋	＋＋
1b	内部和外部接口分析	＋	＋＋	＋＋	＋＋
1c	等价类分析和生成 a	＋	＋	＋＋	＋＋
1d	边界值分析 b	＋	＋	＋＋	＋＋
1e	基于知识或经验的错误推测法 c	＋＋	＋＋	＋＋	＋＋
1f	功能的相关性分析	＋	＋	＋＋	＋＋
1g	相关失效的共有限制条件、次序及来源分析 d	＋	＋	＋＋	＋＋
1h	环境条件和操作用例分析 e	＋	＋＋	＋＋	＋＋
1i	现存标准	＋	＋	＋	＋
1j	重要变量的分析	＋＋	＋＋	＋＋	＋＋
a 为了高效导出必要的测试案例 , 可进行相似性分析。 b 例如 , 逼近或相交于边界 ( 特定值之间 ) 的值 , 和超出范围的值。 c 错误推测测试基于经验教训 , 或者专家判断 , 或者两者结合所收集的数据。错误推测可由 FMEA 支持 d 现存标准包括 ISO 11452 。 e 重要变量的分析包括最恶劣情况分析。

10.4 硬件集成鲁棒性测试

10.4.6 硬件集成和验证活动应验证硬件在环境和运行应力因素下的耐用性和鲁棒性。

为了达到该目的 , 应考虑表 13 所列方法。

表 13 验证在应力下的耐用性，鲁棒性和运行的硬件集成测试

方法		ASIL 等级
方法		A	B	C	D
1a	带基本功能验证的环境测试	＋＋	＋＋	＋＋	＋＋
1b	扩展功能测试	o	＋	＋	＋＋
1c	统计测试	o	●	＋	＋＋
1d	最恶劣情况测试	o	●	o	＋
1e	超限测试	＋	＋	＋	＋
1f	机械测试	＋	＋	＋＋	＋＋
1g	加速寿命测试	＋	＋	＋＋	＋＋
1h	机械耐久测试	＋	＋＋	＋＋	＋＋
1i	EMC 和 ESD 测试	＋	＋	＋	＋
1j	化学测试	＋＋	＋＋	＋＋	＋＋
a 在带基本功能验证的环境测试中 , 硬件安放于多种环境条件下进行硬件要求评估。可采用 GB/T 28046.4 。 b 扩展功能测试检查相关项在极少发生 ( 例如 , 极端性能值 ) 或者硬件规范之外 ( 例如 , 错误命令 ) 的输入条件下的功能表现。在这些情况下 , 把观测到的硬件要素性能与特定要求进行比较。 c 统计测试的目的是 , 根据实际运行条件概况的预期统计分布 , 选定输入数据对硬件要素进行检测。定义验收准则 , 以便测试结果的统计分布能证明所要求的失效率。 d 最恶劣情况测试的目的是测试在最恶劣情况分析时发现的案例。在该测试中 , 调整环境条件至规范定义的最高允许余量值。检验硬件的相关反应并与特定要求相比较。 e 在超限测试中 , 把硬件要素置于环境或功能约束下 , 逐渐增加超过特定值直到硬件要素停止工作或者损坏。该测试的目的是确定要素在测试无故障时间所要求性能时鲁棒性的余量。 f 机械测试适用于机械特性 , 例如 , 抗拉强度。可以应用 1SO 16750-3 。 g 加速寿命测试的目标是通过将产品置于应力大于预期正常操作条件下 , 预测产品在使用寿命内 , 正常条件下产品的行为演化。加速测试是基于失效模式加速的分析模型。 h 这些测试的目的是研究要素能经受住的平均故障间隔期或者最大循环数。测试可以进行到失效发生或者损毁评估时为止。 I GB/T 21437,2 、 GB/T 21437.3 、 1SO 11452-2 和 1SO 11452-4 适用于 EMC 测试； GB/T 19951 适用于 ESD 测试。 j ISO 16750-5 适用于化学测试。