ECU硬件评估与集成验证的功能安全方法

以下文章来源于汽车电子与软件，作者不可说

作者| 不可说

出品| 汽车电子与软件

#01

概 述

遵循ISO26262-5的功能安全方法，在对ECU的硬件安全需求分析与硬件设计之后，还需要做ECU硬件评估与验证，这主要包括对硬件架构的安全性评估，这涉及硬件拓扑结构的全面分析，包括故障模式、故障模式对安全目标的影响、故障率及分布、故障模式的安全机制以及安全机制的故障覆盖能力等关键要素。评估过程中，需要采用业界公认的数据、现场数据、实际运行历史数据以及行业专家评估等手段，以确保数据的准确性和可靠性。

#02

硬件架构指标评估

2.1 目标与内容

硬件架构指标的评估，其核心目的在于深入剖析并验证硬件架构设计在应对随机硬件故障方面的能力。这一评估流程通过一系列精心设计的硬件架构指标，为硬件架构的有效性提供了坚实的量化证据，从而确保其能够全面满足功能安全的高标准要求。具体来说，这些关键性指标涵盖了单点故障指标（SPFM）与潜在故障指标（LFM），它们共同作用于评估硬件架构对于单点故障及潜在故障的广泛覆盖率，为系统的整体可靠性提供了有力支撑。

硬件架构指标的全面评估，主要围绕以下两个至关重要的核心指标展开：

单点故障指标（Single Point Fault Metric, SPFM）：该指标专注于衡量硬件架构在面对单点故障及其可能引发的残余故障时的覆盖程度。一个较高的SPFM值，不仅意味着硬件架构在遭遇单点故障时能够展现出卓越的容错与恢复能力，还体现了其设计上的高度鲁棒性，有效降低了因单点失效导致系统整体崩溃的风险。

潜在故障指标（Latent Fault Metric, LFM）：此指标则侧重于评估硬件架构对于潜在故障的识别与应对能力。潜在故障往往难以预测且隐蔽性强，而高LFM值则标志着硬件架构在设计时充分考虑了这些潜在威胁，通过冗余设计、故障检测与隔离机制等手段，显著增强了系统对潜在故障的抵御能力，确保系统能够持续稳定地运行。

2.2 硬件评估指标的计算

硬件架构指标的计算基于硬件元件的故障率和安全机制的诊断覆盖率。具体计算方法如下：

单点故障指标（SPFM）：

其中：

λSPF是单点故障的故障率；

λRF是残余故障的故障率；

λSR,HW是安全相关硬件元件的总故障率。

潜在故障指标（LFM）：

其中：

λMPF,L是潜在故障的故障率

2.3 硬件架构指标的评估

ASIL等级作为衡量汽车功能安全的关键指标，直接决定了硬件架构在应对潜在故障时的性能要求。针对不同ASIL等级，SPFM和LFM设定了明确的目标值，以确保硬件架构能满足相应的安全标准：

ASIL B：这一等级要求硬件架构具备较高的可靠性，其中SPFM需达到90%或以上，LFM则需不低于60%。这意味着在ASIL B等级下，硬件架构应能有效应对绝大多数单点故障，并对潜在故障保持一定的防范能力。

ASIL C：随着安全要求的提升，ASIL C等级对硬件架构的容错能力提出了更高要求。SPFM需达到97%或以上，LFM则需达到80%或以上。这样的设定确保了硬件架构在极端条件下仍能维持稳定运行，大大降低了因故障导致的安全风险。

ASIL D：作为最高等级的ASIL D，其对硬件架构的安全性要求近乎苛刻。SPFM需达到99%或以上，LFM则需达到90%或以上。这标志着在ASIL D等级下，硬件架构几乎能够完全抵御单点故障和潜在故障，为乘客提供最高级别的安全保障。

然而，在实际应用中，硬件架构可能无法直接满足这些目标值。为此，ISO26262-5标准提供了两种替代方法：

分配目标值：通过将目标值细化并分配到各个硬件元件级别，并针对每个元件提供满足这些目标值的合理性说明，以确保整体架构的安全性能。

诊断覆盖率：对于基于故障检测的安全机制，可以使用诊断覆盖率作为替代指标，以评估系统对故障的识别与应对能力。

在硬件架构指标的验证阶段，确保计算过程的正确性和完整性就显得很是重要。验证过程需涵盖以下方面：

数据来源的合理性：确保故障率数据来源于可靠的行业标准或统计分析，以保证数据的准确性和权威性。

计算过程的准确性：严格审查计算公式和参数的正确性，确保计算结果的真实可靠。

目标值的合规性：最终计算结果需与ASIL等级的要求保持一致，以确保硬件架构满足相应的功能安全标准。

#03

随机硬件故障导致安全目标违规的评估

除了通过硬件架构指标评估来确保硬件架构在满足安全目标方面的有效性之外，还需要关注随机硬件故障及其对安全目标的影响，需要证明由于随机硬件故障导致的安全目标违规风险足够低。这一评估确保硬件设计在面对随机故障时仍能保持功能安全。

3.1 评估方法

随机硬件故障导致安全目标违规的评估方法，构成了功能安全评估中的核心环节，主要包括以下两种互为补充的评估途径：

随机硬件故障的概率度量（Probability Metric of Random Hardware Failure, PMHF）：此方法侧重于通过量化分析的手段，精确评估硬件故障对既定安全目标可能产生的潜在影响。它要求我们在深入理解硬件失效机理的基础上，科学合理地计算出硬件故障的概率，并据此判断其对系统安全性的具体威胁程度。

每个原因的安全目标违规评估（Evaluation of Each Cause for Safety Goal Violation, EEC）：这一方法则更加注重于对硬件故障的细致剖析，它要求我们对每一个潜在的硬件故障进行逐一排查，深入分析其对安全目标可能造成的具体影响，从而确保我们能够全面捕捉到所有可能的安全隐患，避免遗漏任何一条可能导致安全目标违规的故障路径。

PMHF评估

流程如下：

定义目标值：依据ASIL等级的不同，我们为PMHF设定了明确的目标值。例如，在ASIL B等级下，我们要求PMHF必须小于10-7每小时；而在更为严苛的ASIL D等级下，这一标准则被提升至PMHF小于10-8每小时，以此确保不同安全等级下的硬件故障概率均能满足相应的安全要求。

故障率计算：在这一步骤中，我们需要对硬件元件的故障率进行精确计算，并充分考虑到安全机制的诊断覆盖率对故障检测效率的影响，从而得出更为准确的故障概率值。

暴露时间评估：此外，我们还需要对故障暴露时间进行全面的评估，这包括故障从发生到被检测出来的时间、车辆的实际行驶时间以及维修所需的时间等，以确保我们能够全面把握故障可能造成的实际影响。

EEC评估

EEC评估则更加注重于对硬件故障的深入剖析：

故障分类：我们首先将硬件故障细分为单点故障、残余故障和潜在故障等不同类型，以便更加精准地定位和分析故障的原因。

故障评估：随后，我们对每一个故障进行逐一评估，深入分析其对安全目标可能造成的具体影响，从而确保我们能够全面捕捉到所有可能导致安全目标违规的故障路径。

诊断覆盖率评估：最后，我们还需要对安全机制的诊断覆盖率进行评估，以确保故障能够被及时有效地检测并处理，从而进一步降低故障对系统安全性的潜在威胁。

3.2 评估结果的验证

为确保评估结果的技术正确性和完整性，我们还需要对评估结果进行严格的验证：

数据来源的合理性：我们会对故障率数据和诊断覆盖率数据的来源进行仔细核查，确保其真实可靠。

计算过程的准确性：对计算公式和参数的正确性进行反复校验，以避免因计算错误而导致的评估结果失真。

目标值的合规性：还会将评估结果与ASIL等级的要求进行逐一比对，以确保评估结果能够完全满足既定的安全标准。

#04

硬件集成与验证

4.1 目标

要确保所开发的硬件组件能够严格遵循并满足既定的硬件安全要求，从而保障整个汽车电子电气系统的功能安全性和可靠性。这一目标的实现，依赖于硬件集成与验证活动，这些活动旨在将各个硬件元件高效地集成到系统中，并通过严格的测试流程来验证其是否达到了预期的功能安全标准。

硬件集成与验证工作的开展，离不开输入信息。硬件集成与验证的输入主要包括以下几个方面：

硬件安全要求规范：它明确列出了硬件组件必须满足的各项安全要求。这些要求涵盖了硬件在功能、性能、可靠性以及故障应对等多个方面的具体标准，为硬件设计和验证提供了明确的指导和约束。

硬件设计规范：描述了硬件设计的各个方面，包括硬件架构、元件选择、连接方式、信号传输路径等。它不仅是硬件设计团队的工作指南，也是硬件集成与验证团队进行验证工作的重要参考。通过审查硬件设计规范，验证团队可以全面了解硬件设计的细节，从而确保验证过程的全面性和准确性。

硬件安全分析报告：这份报告是对硬件进行安全分析后得出的结论性文档。它详细记录了硬件在安全方面可能存在的问题、潜在的风险以及相应的应对措施。硬件安全分析报告为硬件集成与验证团队提供了宝贵的安全信息，有助于他们在验证过程中重点关注那些可能影响硬件安全性的关键环节，从而确保硬件在集成和验证后能够满足既定的安全要求。

4.2 验证方法

需要采用了多元化且系统化的验证方法以确保硬件的可靠性和安全性，具体包括以下几个核心方面：

功能测试：这一环节旨在全面验证硬件组件在正常操作条件下的各项功能是否如预期般准确无误地执行。通过模拟实际工作场景，检查硬件能否实现设计规定的所有功能特性，确保其在正常运作时的高效性和稳定性。

故障注入测试：为了深入评估硬件的健壮性和容错机制，该测试通过人为方式向系统中注入预设的故障条件，观察并记录硬件对这些异常情况的检测、响应及处理过程。这一过程对于揭示潜在的故障处理漏洞至关重要，有助于提升系统的整体安全性和可靠性。

电气测试：此测试聚焦于硬件在规定的电压和电流范围内的电气性能表现，包括电流消耗、电压稳定性、信号完整性等关键参数。通过精确的测量与分析，确保硬件在电气层面符合设计要求，避免因电气不兼容或超限导致的故障。

具体验证流程可以分为以下几个阶段：

制定测试计划：基于硬件的安全需求和功能规格，精心策划并制定一份详尽的测试计划。该计划应涵盖所有必要的测试场景、预期结果、测试资源分配及时间表，为后续的测试执行提供明确指导。

执行测试：严格按照测试计划，逐一实施功能测试、故障注入测试和电气测试。在测试过程中，需确保测试环境的可控性和一致性，以便准确评估硬件性能。

结果分析：对收集到的测试数据进行深入分析，对比预期结果与实际表现，确认硬件是否满足既定的安全标准和功能要求。

问题解决：针对测试中识别出的任何问题或不符合项，迅速制定并实施有效的解决方案，随后进行复测以验证问题是否得到妥善解决。

验证活动的最终成果需以验证报告的形式系统记录，内容详尽且结构清晰，主要包括：

测试计划和测试用例：详尽阐述测试计划的制定逻辑、测试目标、测试策略以及具体的测试用例设计，为读者提供全面的测试背景信息。

测试结果汇总：客观记录每项测试的执行情况及结果，无论是成功的测试用例还是失败的案例，均需详细说明，以便于后续的问题追踪和改进。

问题分析和解决方案：针对测试中发现的任何问题，深入分析其根本原因，提出并实施针对性的解决方案，同时记录解决方案的实施效果，确保所有问题得到有效闭环管理。

#05

实践案例与应用

5.1 案例背景

假设我们正在开发一款汽车电子控制系统，该系统包含一个MCU、多个传感器和执行器。该系统的目标是实现车辆AEB功能，安全目标为“在检测到前方障碍物时，确保车辆在100毫秒内启动制动”。

5.2 硬件架构指标评估

硬件架构指标计算

我们设计了一个包含冗余传感器和备用执行器的硬件架构。微控制器采用双核锁步架构，以提高可靠性。每个硬件元件根据分配给它的最高ASIL等级进行开发。

我们计算了硬件架构的SPFM和LFM指标：

SPFM：通过分析硬件元件的故障率和安全机制的诊断覆盖率，计算出SPFM值为98%。

LFM：通过分析潜在故障的故障率，计算出LFM值为92%。

验证计算结果，确保其满足ASIL D等级的要求（SPFM≥99%，LFM≥90%）。虽然SPFM值略低于目标值，但通过增加冗余设计和优化安全机制，最终满足了要求。

5.3 安全目标违规评估

PMHF评估

我们定义了PMHF的目标值为10−8h⁻¹，并计算了硬件元件的故障率。通过考虑安全机制的诊断覆盖率和故障暴露时间，得出PMHF值为8×10−9h⁻¹，满足目标值要求。

EEC评估

我们对每个硬件故障进行了分类和评估，确保所有可能的故障路径都被覆盖。通过评估安全机制的诊断覆盖率，确认所有故障都能被及时检测和处理。

5.4 硬件集成与验证

硬件集成

我们将微控制器、传感器和执行器集成到系统中，并制定了详细的测试计划。

功能测试

执行功能测试，验证系统在正常操作条件下的性能。所有测试用例均通过，系统功能正常。

故障注入测试

通过注入故障，验证系统的故障检测和处理能力。测试结果表明，系统能够及时检测到故障并进入安全状态。

电气测试

我们执行了电气测试，验证硬件在规定的电压和电流范围内的性能。所有测试用例均通过，硬件性能符合要求。

验证报告

记录了所有测试计划、测试用例和测试结果，并在验证报告中详细描述了测试过程和结果。针对测试中发现的问题，我们制定了解决方案并进行了验证。

#06

小 结

通过硬件架构指标评估、安全目标违规评估和硬件集成与验证，开发团队可以系统地进行硬件开发，确保硬件设计满足功能安全要求。在实际开发过程中，结合具体的技术安全概念和系统架构设计，按照标准的要求进行硬件设计和验证，可以确保汽车电子系统的功能安全。