MUNIK解读ISO26262：读懂硬件开发过程

—原创文章，文章内所有内容文字资料，版权均属本公司所有，任何媒体、网站、公众号或个人未经本公司授权不得转载、转贴、引用或以其他方式复制发布 、发表。已经本公司授权的媒体、网站、公众号、个人，在下载使用时必须注明来源，违者本公众号将依法追究相关责任.

 

回到本文的源头文章“ISO26262标准解读”，请点击链接：ISO26262 Functional Safety of Automotive汽车功能安全服务

回到知识分享，请点击链接：MUNIK中国-技术分享

 

硬件开发阶段属于ISO26262 part5部分的内容，是安全生命周期中系统开发的一部分，可以与软件开发并行。

 

下图是一个简单的硬件开发阶段流程图：

 

 

硬件开发流程图

 

本篇文章将按照硬件开发流程描述每个安全活动的内容，主要分为4个部分：

l                      需求分析

l                      硬件设计

l                      安全分析

l                      硬件集成与测试

 

需求分析：

 

 

 

硬件安全需求是从系统安全需求和系统架构中分解出来的，也就是将影响硬件的技术安全需求细化为硬件安全要求。所以，在系统阶段的需求、架构设计和软硬件接口都完善后，就可以导出硬件安全需求。对于常规硬件开发而言，硬件需求主要侧重于市场的需求、技术的可实施性和成本的效益。

 

硬件安全要求的目的主要有三点，

1）从更高一级的概念中导出具体的硬件设计要求。技术安全概念是提供一个框架，用于如何去理解系统及实现安全目标，系统架构规范则是进一步去描述由哪些元素去组成系统，以及它们间的一些交互。基于这两点，设计开发团队去定义硬件安全需求，确保它的安全性和可追溯性。

2）需要确保软件和硬件可正确交互，确保接口可以在预期条件下正常工作

。3）从概念到实现的过程，每一步都应该去仔细检查和验证，需要其确保预期的功能及与上层目标的关联性，此过程也体现了追溯性。

想要了解更多关于需求管理的内容，可移步此链接：功能安全之需求管理。

 

硬件设计：

 

 

适应于硬件层面的安全需求被提出后，需要进行硬件设计，因为需求是要在具体的硬件设计中实现的。硬件设计包括硬件架构设计和硬件详细设计，硬件架构设计表示所有的硬件组件以及他们彼此的相互关系，从安全的角度来看，硬件的设计应该能够满足对硬件的安全要求，这种设计是为了提供功能安全和保障硬件的实际功能，可以确保系统在面对各种故障和异常情况时仍能保持安全状态，因此，设计中就必须要考虑安全机制的存在。此过程是将技术安全概念和系统架构规范具体化，为后续的硬件详细设计的实现奠定了基础。硬件详细设计是在电子电气原理图级别上，表示构成硬件组件的元器件间的相互连接，这是硬件落地实践的关键，包括原理图设计、电路设计、元器件选择、layout等。对于常规硬件开发而言，一般只侧重于实现规定的功能和性能。

 

硬件设计的目的主要有以下内容：

需要满足硬件安全要求和受软硬件接口规范，确保软硬件正常交互；遵守系统架构设计规范，确保硬件设计与系统架构可兼容；

基于有效的假设进行开发，这些假设应用于每个独立安全要素（SEooC）的集成；

性能、可靠性，耐用性等硬件设计特性也需满足，以保证在生产和服务过程中实现功能安全。

如若有新技术的出现、设计缺陷或者其他因素需要对硬件设计进行更改，整个硬件开发流程需要进行相应的调整以确保设计的更新能够准确反映新的需求，此时就需要对需求分析进行更新，再对硬件设计进行相应的更新。

 

安全分析：

 

 

安全分析的最初目的是支持硬件设计的定义，其后，安全分析能用于硬件设计验证。因此，在进行完硬件设计后，就需要对硬件设计进行安全分析。硬件设计通常包括两个环节，一般来说架构初设完成后实施FMEA，DFA和FTA这样的定性安全分析，以支持硬件设计的定义；在详细初设完成后实施FMEDA这样的定量安全分析，以支持硬件设计验证。FMEA是自下而上的识别底层各个功能的失效模式，进而评估风险，并制定适当措施；FTA是从Safety Goal出发，基于系统架构搭建故障树自上而下识别出所有可能违背安全目标的底层事件；DFA进行相关失效分析是为了提供硬件设计符合独立性要求的证据。通常情况下，这三种分析可以只做定性分析，因为这些安全分析主要是用于支持硬件设计的定义，而标准中提到了以此为目的的安全分析，定性分析可能是适当且充分的。

 

失效模式、影响和诊断分析（FMEDA）这一阶段是与传统硬件设计的区别点，它是在FMEA的基础上发展而来的，加上了失效率以及失效模式的分布和诊断覆盖率。它的目的是在于提供充分的证据，证明硬件架构设计在探测和控制安全相关的随机硬件失效方面的适用性，意味着设计必须能够识别和响应潜在的随机硬件故障，以避免或减轻这些故障对系统安全性的影响。

 

为确保硬件适用于相应的ASIL，必须证明硬件具有足够的安全机制来检测和控制随机硬件故障，必须证明失效的概率足够低。最终硬件的失效率有两个方法去评估：

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

b) “对违背安全目标的每个原因的评估”(EEC)是基于对每个硬件元器件及其在单点失效、残余失效和合理的双点失效方面对违背所考虑的安全目标的影响的独立评估。这两种方法是从不同的角度去评估硬件设计的安全性的，PMHF侧重于通过定量分析去评估整体的随机硬件失效风险，而EEC侧重于对每个硬件元件的失效模式及对安全目标影响的定性分析。

 

结合使用这两种方法，可以更全面地评估和控制硬件系统因随机硬件失效而违背安全目标的风险。所选用的方法在硬件架构设计和硬件详细设计中要能被迭代应用。

 

若在安全分析活动阶段识别出一些单点故障，就表明此时的硬件设计可能未能充分覆盖所有的潜在的安全风险，或者已有的安全措施无法有效用于已识别的故障。这就需要引入新的安全机制，对需求分析进行更新，确保新的安全机制已体现在需求层面，根据更新后的需求分析，调整硬件架构设计和详细设计，再重新进行安全分析。

对于安全分析更为详细的内容，可以移步此链接:系统安全分析/硬件架构指标评估及FMEDA。

 

 

 

硬件集成和验证：

 

 

进行完安全分析后，最后一步是进行硬件集成和验证这个环节。硬件集成和验证的目的是验证硬件在实际运行中是否按照设计要求，正确执行安全相关的功能；确保硬件可以有效检测和响应潜在的故障，采取适当措施；确保硬件组件接口间传输数据的准确度，可以正确的进行通信交流；确保硬件设计能达到必要的汽车安全完整性等级。

 

标准要求对这个阶段进行计划，并指定和成功执行测试。证明指定测试用例已应用了有条理的程序，证明硬件安全要求已成功实施，并且硬件是稳健的。必须根据行业标准进行测试，测试硬件在不同条件下的性能，特别是在异常和极端条件下系统仍能保持预期的功能，eg：功能测试、电气测试、故障注入测试，成功执行硬件测试。

 

硬件可能是基于多个样本迭代开发的，基于在集成和验证阶段的问题发现，对需求分析进行更新，再进行硬件设计的调整和安全分析，在成功集成和测试后完成硬件研发并进行工作成果的发布。

想要了解更多关于功能安全验证活动的内容，可点击此链接：功能安全之验证活动。