V模型视角下的产品硬件开发初探

本文主要介绍的是产品的硬件开发，旨在为诸君辨析硬件的开发如何满足功能安全相应目标。该部分内容位于ISO 26262系列架构的第五部分，由架构图可知硬件开发的主要章节共有六章，由于篇幅原因，本文介绍前三章。

5 硬件开发总论

该章节内容是对硬件开发的整体流程进行梳理。满足功能安全的硬件开发的必要活动和过程在ISO26262-2《安全生命周期管理流程》中已经进行了规划。硬件开发的必要过程如下图：

硬件开发过程模型

这些活动和过程包含以下内容：

a）硬件实现的安全理念；

b）潜在的硬件失效和影响分析；

c）与软件开发的协调合作。

6 硬件安全需求规范

该章节内容主要是对硬件开发的规范进行了要求。

6.4.1规范应来源于分配给硬件的技术安全要求（源自ISO 26262-4:2018，6.5.2）。

6.4.2规范应包含如下信息：

a）硬件安全要求和用于控制硬件内部失效的相关安全机制特性，包括内部安全机制。例如，看门狗的计时与检测能力。

b）硬件安全要求和用于控制硬件外部失效的相关安全机制特性。例如ECU输入开路的外部故障的功能行为。

c）硬件安全要求和与其他安全需求的元素之间相匹配的安全机制特性。例如，传感器与执行器之间的诊断。

d）硬件安全要求和检测内/外部故障并发出信号的相关安全特性。

注意：对于内外部故障的检测与指示还包括防止潜在故障的安全机制，比如故障的反应时间与容错时间的间隔需要一致。

e）硬件安全要求未指明的安全机制。

注意：安全机制可以单独在硬件或者软件中实现，也可以两者结合实现。

6.4.5硬件安全要求在ISO 26262-8:2018第六章中进行了规定。

7 硬件设计

这一章节开始，进入硬件设计的主题。在进行设计之前我们需要先了解硬件设计的目的，再依循目的进行产品的设计。

7.1 目的

a）建立如下硬件：

——支持安全导向分析；

——考虑安全导向分析的结果；

——满足硬件安全需求；

——满足软硬件接口规范；

——符合系统结构设计规范；

——满足硬件需求的属性。

b）特定需求并且提供在生产、运行期间硬件的功能安全信息；

c）验证：

——满足硬件安全要求和软硬件接口规范；

——有效性；

——功能安全相关的特殊特性。

7.2 硬件设计包括硬件架构设计和硬件详细设计。

硬件架构设计指：所有硬件组件及其相互之间的交互关系；

硬件详细设计指：在原理图层次上，表示元件之间的相互连接关系。

7.4.1硬件架构设计

7.4.1.2硬件安全要求应分配到元件。每个硬件元件应该按照分配给它最高ASIL进行开发。

7.4.1.4如果一个硬件元件是由ASIL低于该元件ASIL或没有ASIL分配的子元件组成的，那么每个子元件都应按照最高ASIL处理，除非满足ISO 26262- 9: 2018第6条规定的共存标准。

7.4.1.6为了避免系统故障，硬件架构设计应通过使用表1所列的原则表现出以下特性：

a）模块化；

b）适当的粒度级别；在细节上提供必要的信息，以显示安全机制的有效性。

c）简易性。

表1硬件架构设计特性

7.4.1.7在硬件架构设计期间，应考虑与安全相关的硬件组件的非功能性失效原因，如温度、振动、水、灰尘、EMI、噪声或来自硬件架构的其他硬件组件或其环境的串扰。

7.4.2硬件详细设计

7.4.2.1为避免常见的设计失效，应按照ISO 26262-2:2018，5.4.2.6应用相关经验教训。

7.4.2.2在硬件详细设计时，应考虑与安全相关的硬件部件的非功能性失效原因，包括以下影响：温度、振动、水、灰尘、EMI、噪声或来自硬件部件的其他硬件部件或其环境的串扰。

7.4.2.3应考虑硬件部件或它的任务概况和运行条件，以确保在其规范内运行，以避免因预期使用而发生故障。

7.4.2.4应该考虑稳健的设计原则。

注：稳健的设计原则可以通过使用硬件设计指南来显示。

7.4.3安全分析

7.4.3.1对于硬件设计的安全分析，应按照表2和ISO 26262-9:2018第8条进行。

表2硬件设计安全分析

7.4.3.2此要求适用于安全目标为ASIL（B）、C和D。对于每个与安全相关的硬件组件或部件，安全分析应考虑以下内容：

a）安全故障；

b）单点故障或残留故障；

c）多点故障（可感知、可检测或潜在的）。

注：识别多点故障的目的并非要求对硬件故障的每一种可能组合进行系统分析，而是至少要考虑源自技术安全概念的组合（例如两个故障的组合，其中一个故障影响与安全相关的元素，另一个故障影响旨在实现或维持安全状态的相应安全机制）。

7.4.3.3此条适用于ASIL（A）、B、C和D。应提供为防止故障导致单点故障或减少剩余故障而实施的安全机制的有效性的证据。其目的：

a）应提供安全机制实现和维持安全状态能力的证据（特别是在容错时间间隔和最大故障处理时间间隔内适当的故障缓解能力）；

b）对于由安全机制实现的残余故障的诊断覆盖率应进行评估。

注：如果相关安全机制的故障检测时间间隔加上故障反应时间间隔大于相应的容错时间间隔或指定的最大故障处理时间间隔，则不能认为在任何时间都可能发生的故障被有效覆盖了。

注：如果可以证明某一种故障模式只会在上电时发生，并且在车辆行程中发生的概率可以忽略不计，那么仅在启动时对这些故障模式进行测试是可以接受的。

注：可以使用FMEA或FTA等分析来构建基本原理。

注：此要求适用于在硬件、软件或两者的组合中实现的安全机制。

7.4.3.4此条适用于ASIL（A）、B、C和D。应提供为防止潜在故障而实施的安全机制的有效性的证据。其目的：

a）应提供安全机制检测故障，并在可接受的潜在多点故障检测时间间隔内实现或保持安全状态或通知驾驶员的能力的证据，以确定哪些故障将继续潜在，哪些故障可检测到。

b）应评估安全机制对潜在故障的诊断覆盖率。

注：如果相关安全机制的故障处理时间间隔大于潜在故障的相关多点故障检测时间间隔，则不能认为故障被覆盖。

7.4.3.6如果硬件设计引入的新危害没有被现有的HARA报告所涵盖，则应根据ISO 26262-8:2018第8条的变更管理流程引入和评估。

注：目前安全目标尚未涵盖的新识别的危险通常是非功能性危险。非功能性危害不在ISO 26262的范围内，但可以在危害分析和风险评估中做如下注释：该危害不属于ASIL，因为它不在ISO 26262的范围内。但是可以指定一个ASIL作为参考。

7.4.4硬件设计验证

7.4.4.1硬件设计应按照ISO 26262-8:2018第9条进行验证，并使用表3中列出的硬件设计验证方法为以下事项提供证据：

a）满足硬件安全需求；

b）符合软硬件接口规范；

c）与安全相关的特殊特性在生产和服务过程中，实现功能安全的适宜性。

表3硬件设计验证

7.4.4.2如果在硬件设计过程中发现任何硬件安全要求的实施是不可行的，应根据ISO 26262-8：2018的变更管理流程第8条发出变更请求。

7.4.5生产、运营、服务与关闭

7.4.5.1与安全有关的特殊特性应包括：

a）生产、运营验证方法；

b）这些措施的验收标准。

7.4.5.3根据ISO 26262-7:2018的5.4.1.2和5.4.3.3的要求，与安全相关的硬件要素应具有可追溯性，以便：

a）启用有效的现场监测；

b）启用召回或更换管理。

公众号文章链接：基于V模型的产品硬件开发（一）