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

写在前面

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

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

---

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

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

一、硬件级产品开发初始化

在硬件产品开发的启动阶段的目的是确定和规划在硬件开发的各个子阶段功能安全活动。规定的硬件安全活动计划包含在项目的安全计划中。

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

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

——潜在的硬件故障及影响分析

——与软件开发的协调

与软件开发子阶段相比，这部分的 ISO26262 包含两个条款描述项目的总体硬件结构定量评估。第 8 条款介绍了两个指标来评估该项目的硬件架构和实施安全机制的有效性来面向随机硬件故障。作为第 8 条的补充，，第 9 条描述了两种备选方案，以评估违反安全目标行为的残余风险是否足够低，或者通过使用一个全局性的概率方法或使用割集分析，研究确定违反安全目标的每个硬件元件故障的影响。

根据 ISO26262-2 的安全计划详细说明应包括，确定适当的方法和措施，硬件级别的产品开发活动是一致于在 ISO26262-6 中策划的活动。

项目硬件的开发过程包括方法和工具，与整个硬件开发的各个子阶段相一致，并与系统和软件子阶段相一致，使有关规定保持其在硬件开发过程中的准确性和一致性。

硬件开发的安全生命周期应符合 ISO26262 的规定。 硬件单元的复用，或合格硬件单元的使用应在安全活动中进行说明和确认。

二、硬件安全需求规范拟定

该条款的第一个目标是规定硬件安全需求，参考技术安全概念和系统安全规范。第二个目标是验证硬件安全需求与技术安全概念和系统安全规范一致。更进一步的目标是详细描述软硬件接口规范 HSI。

技术安全需求分配到软件和硬件，硬件安全需求进一步详细,考虑设计约束,这些设计约束在硬件上的影响。

硬件安全需求规范应该是硬件上的技术安全要求，应该包含如下内容：

1. 硬件安全需求和相关安全机制的属性来控制硬件单元的内部失效,这包括内部安全机制覆盖瞬态故障,例如,使用的技术。相关属性可以包括定时器和看门狗检测。

2. 硬件安全需求和相关安全机制的属性能够承受外部单元的失效。例如在 ECU 外部失效时，对 ECU 输入开路。

3. 硬件安全需求和相关安全机制的属性能够匹配别的单元的安全需求。

4. 硬件安全需求和相关安全机制的属性能够检测和指示内部和外部故障。

5. 硬件安全需求不指定安全机制 产品硬件的设计验证标准，包括环境条件（温度，振动，电磁干扰，等），具体的操作环境（电源电压，任务历程等）和特定组件的要求。

硬件安全要求应按照 ISO 26262-8:2011 条款 6 和 9 验证，具有以下属性：

1. 与技术安全概念 、系统设计规范、硬件设计规范一致。

2. 技术安全需求分配给硬件单元的完整性。

3. 与相关软件安全需求的一致性。

4. 正确性和精确性。

三、硬件设计

这一条款的第一个目标是根据系统设计规范和硬件安全需求设计硬件，第二个目标是验证设计。 硬件设计包括硬件架构设计和硬件详细设计，硬件架构设计应表示出所有硬件单元及彼此间的关系，硬件详细设计是指在电路原理图上的设计。

1. 硬件架构设计

硬件架构应实现硬件的安全要求，每个硬件单元应根据硬件安全要求实现最高的 ASIL。硬件安全要求和实现之间的可追溯性应保存到的硬件单元的最低层，但不需要到硬件详细设计，ASIL 不会分配到硬件元件。

为了避免高复杂性产生的故障，硬件体系架构设计应通过使用表 1 列出原则来具有以下特征：

• 模块化
• 粒度合适
• 简易性

Properties		ASIL
		A	B	C	D
1	Hierarchical design（分层设计）	+	+	+	+
2	Precisely defined interfaces of safety-related hardware components（与安全相关的硬件精确定义接口）	++	++	++	++
3	Avoidance of unnecessary complexity of interfaces （避免不必要的复杂接口）	+	+	+	+
4	Avoidance of unnecessary complexity of hardware components （避免不必要的复杂硬件组件接口）	+	+	+	+
5	Maintainability during service（后期服务的可维护性）	+	+	++	++
6	Testability during development and operation （开发运行过程中的可测试性）	+	+	++	++

对于安全相关的硬件组件故障，在硬件设计过程中的非功能性条款应考虑以下的影响：

温度，振动，湿度，灰尘，电磁干扰，无论是从硬件结构的硬件组件或从其他它的环境的串扰源。

2. 硬件详细设计

• 为避免设计缺陷，相关的经验教训应该遵循组织的安全文化。
• 与安全相关的硬件部分失效时应考虑硬件详细设计过程中的非功能性原因，包括以下几方面的影响，如：温度，振动，湿度，灰尘，电磁干扰，噪声系数，无论是从硬件组件的其他部件或它的环境的串扰源。
• 硬件部分的操作条件应满足他们的环境和操作限制的规范。
• 应该考虑稳健设计原则，稳健设计原理，可以利用基于 QM 方法清单。例如保守的组件规范

3. 安全分析

在硬件设计上找出故障原因和故障影响的安全性分析依据下表和 ISO 26262-9:2011条款8。安全分析的最初目的是支持的硬件设计规范。随后，安全分析可用于硬件设计验证。

Methods		ASIL
		A	B	C	D
1	Deductive analysis（推理分析）	0	+	++	++
2	Inductive analysis（归纳分析）	++	++	++	++
a:A typical deductive analysis method is FTA. b:A typical inductive analysis method is FMEA.

本要求适用于安全目标 ASIL（B），C，D。每一个安全相关的硬件部件或零件，在确定的安全目标下，安全分析应考虑以下因素：

• 安全故障
• 单点故障或残留故障
• 多点故障（或感知，检测或潜在的）

在大多数情况下，可以将分析限于双点故障。但多点故障比双点故障点故障两个以上的可以显示更高的技术安全概念（例如当实现冗余安全机制）。

双点故障的识别目的是不需要对每一个可能的两个硬件组合的故障进行系统分析，但是，至少，从安全技术概念考虑到组合，（例如两个故障达到或维持一个安全的状态，一个故障影响安全相关的元素，另一故障影响相应的安全机制）。

• 单点故障

单点故障，是在一个单元中，未被安全机制覆盖且直接会导致违反安全目标的硬件故障。 这项规定应用于安全目标 ASIL（B），C 和 D 的，避免单点故障的有效性安全机制证据，应当提供：

——应提供保持安全状态的安全机制，或安全地切换到安全状态的能力，（特别是恰当的缓解故障的容错时间间隔内的能力）

——应评估关于残余故障的诊断覆盖率

注意 1：如果诊断测试间隔，加上相关安全机制的故障响应时间，超过有关容错的时间间隔，可以发生在任何时候（例如，不仅在上电时）的故障不能被认为是有效地覆盖。

注意 2：如果故障是可以描述为仅发生在上电时刻，车辆行驶过程中，然后接通电源后，对故障执行测试。

注意 3：采用诸如 FMEA 或 FTA 的分析方法用来组成基本原理。

注意 4：依据硬件组件和他们相关层的失效模式的知识，评价可以是硬件组件的任一个全局范围的诊断，或更详细的故障模式覆盖的评价。

• 潜在故障

潜在故障，是在多点故障检测时间间隔内不能被安全机制检测出来的也不能被驾驶员识别的多点故障。 这项规定应用于安全目标 ASIL（B），C 和 D 的，避免潜在故障的有效性安全机制证据，应当提供：

——故障检测，并通知到驾驶员的能力，对潜在故障可接受的多点故障检测的时间间隔内，应以确定哪些故障潜伏，哪些故障是不能潜伏的。

——对潜在故障的诊断覆盖率进行评价。

注意 1：故障不能被认为是覆盖，如果它的诊断测试间隔，加上相关的安全机构的故障

响应 时间，比潜在故障相关的多点故障检测时间间隔长，则认为故障不能被覆盖。

注意 2：采用诸如 FMEA 或 FTA 的分析方法用来组成基本原理。

---

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

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

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