道路车辆功能安全 ISO 26262标准（5-2）—硬件级产品开发

零零刷

2172人浏览 · 2024-10-17 07:30:00

零零刷 · 2024-10-17 07:30:00 发布

写在前面

本系列文章主要讲解道路车辆功能安全ISO26262标准的相关知识，希望能帮助更多的同学认识和了解功能安全标准。

若有相关问题，欢迎评论沟通，共同进步。(*^▽^*)

1. 道路车辆功能安全ISO 26262标准

5. ISO 26262-5 硬件级产品开发

4. 硬件设计验证

硬件设计应按照 ISO26262-8，第 9 条，针对硬件安全要求合理性和完整性进行验证。为了实现这一目标，在下表中列出的方法，应考虑。

Methods		ASIL
Methods		A	B	C	D
1a	Hardware design walk-through	++	++	o	o
1b	Hardware design inspection	+	+	++	++
2	Safety analyses	参考安全分析
3a	Simulation	o	+	+	+
3b	Development by hardware prototyping	o	+	+	+
a:Methods 1a and ib serve as a check of the complete and corect implementaion of the hardware safety requirements in the hardware design. b:Methods 3a and 3b serve as a check of particular points of the hardware design (e.g. as a fault injection technique) for which analytical methods 1 and 2 are not considered to be sufficient.

注意：此验证审查的范围是硬件设计的技术正确性。

在硬件设计中，如果发现何硬件安全要求的实施是不可行的，应当按照 ISO26262-8 的变更管理流程发出变更请求。

5. 生产、运行、服务和关闭

如果安全分析已经表明，它们是与安全有关的特殊特性相关的，那么这些特殊特性应被指定。特殊特性的属性应包括：

生产运行的核查措施
这些措施的验收标准

四、硬件体系指标评估

这一条款的目的是评估由故障处理的指标要求来设计的项目硬件架构。

这一条款描述了两个硬件体系结构的评价指标的有效性，项目的架构来应对随机硬件故障。这些标准和相关的目标值适用于整个项目的硬件。这些指标涉及的仅限于一些项目的安全相关的电气和电子硬件部分随机硬件故障，即那些能够显著有助于违规或实现的安全目标，对于单点，剩余的和这些部件的潜在故障。对于电气硬件单元，只考虑电气故障模式和故障率。硬件架构指标可以反复的在硬件架构设计和硬件详细设计过程中应用。硬件体系结构

指标依赖于产品的整个硬件。符合规定的硬件架构度量的目标值满足项目所涉及的每个安全目标。

定义这些硬件架构指标来实现以下目标：

客观上应是可评价的：指标是可验证的，精确区别不同的架构
支持最终设计评估
使 ASIL 依赖于通过/失败标准
揭示安全机制的覆盖面，防止硬件架构单点或残留故障风险
揭示安全机制的覆盖面，防止硬件架构潜在故障风险
提出单点故障、残余故障和潜在故障
确保硬件故障率不确定性的鲁棒性
限于安全相关的元素
支持不同元素的语法，例如目标值能分配给供应商元素

要求和建议

这项规定安全机制的安全相关的诊断覆盖率应就剩余的故障和有关潜在故障评估适用于安全目标 ASIL（B），C 和 D。分析硬件部分的故障率应由以下几个方法确定：

使用从工业界认可的工业数据源中得到的硬件故障率数据，例如，公认的业内人士以确定硬件部分的故障率和故障模式分布，包括 IEC/ TR62380，IEC61709，MIL HDBK217 F通知 2，RIAC HDBK217 此外，UTE C80-811，NPRD95，EN50129:2003，附件 C，IEC62061:2005，附件 D，RIAC FMD97 和 MIL HDBK338。
使用基于现场返回或测试数据。在这种情况下，失效率必须有足够的置信水平。
使用工程上基于定量和定性参数的专家判断方法。专家判断应按照结构化的标准来行使这一判断的依据。这些标准应设置故障率的估算适用于安全目标 ASIL（B），C 和 D。如果不能提供一个单点故障或潜在故障的计算故障率的充分证据，应提出替代手段（例如添加安全机制来检测和控制这个故障）。

对于每一个安全目标，量化指标值根据 ISO26262-4:2011，7.4.4.2 规定的“单点故障指标”一样，应根据以下参考目标值来源之一：

对硬件架构的指标计算
依据下表

	ASIL B	ASIL C	ASIL D
Single-point fault metric	≥90%	≥97%	≥99%

对于每一个安全目标，量化指标值根据 ISO26262-4:2011，7.4.4.2 规定的“潜在故障指标”一样，应根据以下参考目标值来源之一：

对硬件架构的指标计算
依据下表

	ASIL B	ASIL C	ASIL D
Latent-fault metric	≥60%	≥80%	≥90%

五、随机硬件故障对安全目标影响评价

对于随机硬件失效率指标的规定：

六、硬件集成和测试

这一条款的目的是通过测试确保开发的硬件满足硬件安全要求。本节所述活动的目的是集成硬件单元和测试硬件设计以验证其符合适当的 ASIL 硬件安全要求。

硬件集成和测试不同于 ISO26262-8:2011，第 13 条的硬件组件活动的限制，它给出了中级层硬件组件符合 ISO26262 的证据。

硬件集成和测试活动，应当按照 ISO26262-8:2011，第 9 条进行。
硬件集成和测试活动，应符合 ISO26262-4:2011，5.5.5 中给出的项目集成和测试计划。
测试设备应该属于质量监控系统。
硬件集成和测试活动应验证对硬件的安全要求实现的安全机制的完整性和正确性。测试方法下表所示：

Methods		ASIL
Methods		A	B	C	D
1	Functional testing	++	++	++	++
2	Fault injection testing	+	+	++	++
3	Electrical testing	++	++	++	++
a:Functional testing aims at verifving that the specified characteristics of the item have been achieved. The item is given input data,which adequately characterises the expected normal operation. The outputs are observed and their response is compared with that given by the speciication. Anomalles wth respect to the speciicaton and indicatons of an incomplete specification are analysed. b:Fault injection testing aims at introducing fauts in the hardware product and analysing the response. This tesing is approprate whenever a safety mechanism is defined. Model-based fault injection (e.g. fault injection done at the gate-level neltist level) is also applicable, especially when fault injection testing is very dificult to do at the hardware product level. For example, showing the response of safety mechanisms to transient faults inside hardware parts, such as a microcontroller, is very difficult to do with fault insertion at the hardware product level since it would require irradiation tests. c:Electrical tesing aims at verifyving compliance with hardware safety requirements within the specifed (staic and dynamic) voltage range.

硬件集成和测试活动，应当验证硬件抵抗外部应力的健壮性。如下表所示：

Methods		ASIL
Methods		A	B	C	D
1a	Environmental testing with basic functional verification	++	++	++	++
1b	Expanded functional test	o	+	+	++
1c	Statistical test	o	o	+	++
1d	Worst case test	o	o	o	+
1e	Over limit test	+	+	+	+
1f	Mechanical test	++	++	++	++
1g	Accelerated life test	+	+	++	++
1h	Mechanical Endurance test	++	++	++	++
1i	EMC and ESD test	++	++	++	++
1j	Chemical test	++	++	++	++

本文章是博主花费大量的时间精力进行梳理和总结而成，希望能帮助更多的小伙伴~ 🙏🙏🙏

后续内容将持续更新，敬请期待(*^▽^*)

欢迎大家评论，点赞，收藏→→→

天工造物局

北京人形旗下天工造物具身智能开源社区，聚焦具身天工与慧思开物两大平台

更多推荐

deck.gl TripsLayer 出租车轨迹动画示例实战：从示例运行到着色器原理

TripsLayer 是 deck.gl 中用于渲染**随时间流动的轨迹动画**（如出租车行程、物流路径、迁徙路线）的核心图层。本文以仓库中的最小独立示例 [examples/website/trips](https://link.gitcode.com/i/1442af8f442f4cff39ff546e050fceb5) 为骨架，带你完成从安装依赖、启动应用、理解曼哈顿出租车数据格式，到深入

天工造物局

Foundry Anvil 中 eth_simulateV1 的 Blob 交易与 Blob Gas 字段规范化：原理、实现与测试验证

本篇技术指南以 [anvil-simulate-blob-transactions.md](https://link.gitcode.com/i/3d2ebe227262de169335eb290af80da8) 这条 changelog 条目为起点，深入剖析 Foundry Anvil 对 `eth_simulateV1` RPC 返回结果中 blob（EIP-4844）交易与 blob gas

天工造物局

LMCache CLI 实战：用 `lmcache kvcache clear` 管理运行中服务的 KV Cache 状态

本文是一份针对 LMCache 官方 CLI 命令 `lmcache kvcache` 的完整技术指南。该命令用于在**运行中的 LMCache 服务（MP HTTP server）**上管理 KV cache 状态，当前提供 `clear` 子命令，用于清空 L1（CPU 内存）层中缓存的全部 KV 数据。读完本文，你将掌握该命令的完整参数体系、退出码语义、终端/JSON/静默三种输出模式，并能