22、汽车软件与硬件可靠性深度剖析

汽车软件与硬件可靠性深度剖析

汽车软件发展现状与挑战

汽车软件开发者在开发方法上面临诸多挑战，随着汽车功能的增加，代码复杂度上升，可靠性和安全性问题也日益凸显。汽车软件开发环境的标准化促使众多汽车行业领先企业提出了AUTOSAR概念，它为基础软件和接口提供了一致性和方法论，支持开发阶段的可重用性和可扩展性。AUTOSAR合作伙伴成员相互合作开展重要研究，既提升汽车软件成熟度，又在实施AUTOSAR标准方面相互竞争。

汽车功能的复杂性要求与传统基于微控制器的软件采用不同的方法。例如，应用于车道偏离预警系统（LDWS）和车道保持辅助系统（LKAS）的视觉处理功能需要强大的计算能力，即使是最先进的32位微控制器也难以满足。片上系统（SoC）是一个很好的替代方案，它在智能手机等IT行业已广泛应用。在AUTOSAR环境中，硬件加速器可在复杂设备驱动程序中实现，而不是在分层架构的任何一层实现，因为通过分层架构访问可能会导致性能下降，在视觉处理中，计算能力比可重用性和可扩展性更为重要。

在AUTOSAR系统集成和进一步开发之前，在虚拟功能总线（VFB）上对软件组件（SWC）进行仿真，有助于验证AUTOSAR SWC的功能，这些SWC是AUTOSAR系统的应用软件开发组件。

AEC - Q100电气组件资格要求

汽车电子委员会（AEC）组件技术委员会定义了通用电气组件资格要求，包括详细的资格和重新资格要求，以及独特的测试方法和通用数据使用指南。符合这些规范的组件适用于恶劣的汽车环境，无需额外的组件级资格测试。

AEC - Q100包含一组基于故障机制的应力测试，定义了集成电路（IC）资格的最低应力测试驱动资格要求、参考和测试条件。这些测试可刺激和加速半导体器件和封装故障的出现，具体测试项目如下：
- AEC - Q100 - 001：焊线剪切测试
- AEC - Q100 - 002：人体模型（HBM）静电放电（ESD）测试
- AEC - Q100 - 003：机器模型（MM）静电放电（ESD）测试
- AEC - Q100 - 004：IC闩锁测试
- AEC - Q100 - 005：非易失性存储器写入/擦除耐久性、数据保留和使用寿命测试
- AEC - Q100 - 006：电热诱导寄生栅极泄漏（GL）测试
- AEC - Q100 - 007：故障模拟和测试分级
- AEC - Q100 - 008：早期失效率（ELFR）
- AEC - Q100 - 009：电气分布评估
- AEC - Q100 - 010：焊球剪切测试
- AEC - Q100 - 011：带电设备模型（CDM）静电放电（ESD）测试
- AEC - Q100 - 012：12V系统智能功率器件的短路可靠性表征

在AEC - Q100标准规定的测试条件下，制造汽车芯片的半导体公司需报告每个测试类别的资格测试结果，以下是测试结果总结：
| 测试项目 | 通过情况 |
| — | — |
| 高温工作寿命（HTOL）耐久性循环 | 0/231件 |
| 数据保留耐久性循环 | 0/231件 |
| 动态早期失效研究 | 0/2400件 |
| 预条件测试 | 0/924件 |
| 高温储存寿命测试 | 0/231件 |
| 压力锅测试 | 0/231件 |
| 温度循环测试 | 0/231件 |
| 高加速应力测试 | 0/231件 |
| ESD - HBM | 0/36件 |
| ESD - MM | 0/36件 |
| ESD - CDM | 0/9件 |
| 闩锁测试 | 0/18件 |

ISO 26262道路车辆功能安全要求

ISO 26262是汽车行业的功能安全标准，汽车制造商为了生产有竞争力的产品，需要进行标准化开发过程，并要求供应商也遵守这些标准。该标准涵盖了所有与汽车应用相关的安全电气/电子（E/E）系统。

ISO 26262是基于风险的安全标准，它定性评估危险操作情况的风险，定义了避免或控制系统性故障、检测或控制随机硬件故障以及减轻其影响的安全措施。其主要特点如下：
- 提供汽车安全生命周期（管理、开发、生产、运营、服务、退役），支持在这些生命周期阶段调整必要的活动。
- 涵盖整个开发过程的功能安全方面，包括需求规范、设计、实现、集成、验证、确认和配置等活动。
- 提供特定于汽车的基于风险的方法来确定汽车安全完整性等级（ASIL）。
- 使用ASIL来指定产品达到可接受残留风险所需的安全要求。
- 提供验证和确认措施的要求，以确保达到足够和可接受的安全水平。

与IEC 61508标准不同，ISO 26262考虑了可控性，即驾驶员避免危险事件的能力。根据严重程度、暴露概率和可控性，ISO 26262将ASIL分为四个不同级别。确定ASIL后，产品将按照相应ASIL的方法和措施进行开发，实施该标准的主要目的是记录从开发过程到确保功能安全的所有与安全相关的活动。

ISO 26262由10个部分组成：
1. 词汇表
2. 功能安全管理
3. 概念阶段
4. 产品开发：系统级
5. 产品开发：硬件级
6. 产品开发：软件级
7. 生产和运营
8. 支持过程
9. 基于ASIL和安全导向的分析
10. 指南

产品开发过程通常遵循V型过程模型，从概念阶段导出功能安全概念，然后开始系统级产品开发。在产品开发阶段，指定系统设计，并分别启动硬件和软件级的开发过程。

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A([概念阶段]):::startend --> B(导出功能安全概念):::process
    B --> C(系统级产品开发):::process
    C --> D(指定系统设计):::process
    D --> E(硬件级开发):::process
    D --> F(软件级开发):::process

硬件开发过程从规划硬件开发开始，包括指定硬件设计中使用的方法和措施。接下来，指定硬件安全要求，这些要求来自技术安全概念、软件安全要求和系统设计规范等多个来源。硬件安全要求规范应与这些文档保持一致，硬件根据硬件安全要求规范进行设计。在硬件设计过程中，对于ASIL C和D，需要评估和验证与随机硬件故障相关的硬件架构指标。

随机硬件故障通常在硬件元件中任意发生，但其故障率可以合理准确地预测。随机硬件故障数据可从以下几个来源获得：
- 使用公认的行业来源，如IEC 62380、IEC 61709、MIL HDBK 217 F notice 2等。
- 使用基于现场返回或测试的统计数据。
- 使用基于工程方法的专家判断。

为了计算硬件架构指标，需要定义故障模式。安全相关硬件元件中发生的每个故障可分类如下：
- 安全故障：故障发生不会显著增加违反安全目标的概率。
- 多点故障：多个独立故障中的一个，组合起来导致多点故障（可感知、已检测或潜在）。
- 可感知：在规定时间内，驾驶员在无安全机制检测的情况下推断出的故障。
- 已检测：安全机制在规定时间内检测到的故障，以防止故障潜伏。
- 潜在：安全机制未检测到且驾驶员未感知到的故障。
- 单点故障：元件中未被安全机制覆盖的故障，直接导致违反安全目标。
- 残留故障：硬件元件中本身导致违反安全目标的故障部分，且该部分故障未被现有安全机制覆盖。

硬件架构指标计算

为了获得硬件设计的客观证据，对于ASIL C和D，需要按照以下步骤计算硬件架构指标：
1. 估计单点故障和潜在多点故障的故障率 ：可从上述提到的行业来源、统计数据或专家判断等途径获取故障率数据。
2. 估计安全机制的诊断覆盖率 ：诊断覆盖率可通过硬件架构中使用的每个元件或部件及其可实现的诊断覆盖率来计算。以下是一些组件及其故障或失效情况，以及不同诊断覆盖率下的要求示例：
| 组件 | 低（60%） | 中（90%） | 高（99%） |
| — | — | — | — |
| 继电器 | 不励磁或不消磁 | 不励磁或不消磁，单个触点焊接 | 不励磁或不消磁，单个触点焊接 |
| 不变存储器范围 | 数据和地址固定故障 | 数据和地址直流故障模型 | 影响存储器中数据的所有故障 |
| 可变存储器范围 | 数据和地址固定故障 | 数据和地址直流故障模型 | 数据和地址直流故障模型，存储单元动态交叉，无、错误或多次寻址 |

对于可变存储器，不同诊断技术/措施及其可实现的最大诊断覆盖率如下：
| 诊断技术/措施 | 最大诊断覆盖率 |
| — | — |
| RAM测试“棋盘格”或“行进” | 低 |
| 一位冗余 | 低 |
| 使用错误检测纠正码（EDC）检测RAM数据故障 | 高 |
| 块复制 | 高 |

3. 计算“单点故障指标”和“潜在故障指标” ：在估计所有故障率后，通过相关方程计算这两个指标。
4. 将指标与目标值进行比较 ：不同ASIL级别的“单点故障指标”和“潜在故障指标”的数值目标值如下：
   | ASIL级别 | 单点故障指标（%） | 潜在故障指标（%） |
   | — | — | — |
   | ASIL B | >90 | >60 |
   | ASIL C | >97 | >80 |
   | ASIL D | >99 | >90 |

通过比较计算得到的指标与目标值，可以判断产品是否符合标准。然而，对于嵌入数字/模拟电路和各种存储组件的车载片上系统（SoC），估计故障率和诊断覆盖率非常困难。SoC缺陷建模为固定、桥接、延迟、串扰、保留等，每个故障的故障覆盖率和故障率难以简单估计。对SoC进行诊断比估计故障率更具挑战性。为了减轻故障分析的困难并提高可靠性，在设计SoC时采用了临时和结构化的可测试性设计技术。车载SoC需要最先进的可靠性设计技术来达到ISO 26262硬件功能安全的ASIL D级别。尽管开发符合ISO 26262的产品并非易事，但汽车公司应提前在开发过程中实施该标准，以证明其在未来执行功能安全的组织能力。

汽车软件与硬件可靠性深度剖析

故障诊断架构与设计技术

为了提高汽车硬件的可靠性，需要采用各种故障诊断架构和设计技术。以下是一些常用的设计可测试性技术：
- 扫描设计 ：通过在电路中添加扫描链，将内部状态信息串行输出，方便进行故障检测和诊断。
- 内置自测试（BIST） ：在芯片内部集成测试电路，能够自动对芯片进行测试，检测故障并提供诊断信息。
- IEEE边界扫描设计 ：遵循IEEE标准，利用边界扫描单元对芯片的输入输出引脚进行测试，可检测引脚故障和芯片间连接故障。
- 错误纠正码（ECC） ：用于检测和纠正存储系统中的数据错误，提高数据的可靠性。

这些设计技术可以有效地增加硬件的可靠性，减少故障发生的概率。例如，扫描设计可以在芯片生产测试阶段快速定位故障，而ECC可以在系统运行过程中实时检测和纠正数据错误。

汽车电子系统可靠性总结

汽车电子系统的可靠性对于车辆的安全和性能至关重要。随着汽车功能的不断增加和电子系统的日益复杂，可靠性问题也变得更加突出。

从软件方面来看，AUTOSAR概念的提出为汽车软件开发提供了一致性和方法论，支持可重用性和可扩展性。在开发过程中，对SWC在VFB上进行仿真有助于验证功能。

从硬件方面来看，AEC - Q100标准规定了电气组件的资格要求，确保组件能够在恶劣的汽车环境中可靠工作。ISO 26262标准则是汽车行业的功能安全标准，通过对ASIL的分级和硬件架构指标的计算，保证了硬件的功能安全。

为了提高硬件可靠性，采用了各种故障诊断架构和设计技术，如扫描设计、BIST、IEEE边界扫描设计和ECC等。

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A([汽车电子系统]):::startend --> B(软件方面):::process
    A --> C(硬件方面):::process
    B --> D(AUTOSAR概念):::process
    B --> E(SWC仿真):::process
    C --> F(AEC - Q100标准):::process
    C --> G(ISO 26262标准):::process
    C --> H(故障诊断架构和设计技术):::process

未来展望

随着汽车技术的不断发展，汽车电子系统将变得更加复杂和智能化。未来，汽车软件将承担更多的功能，如自动驾驶、智能互联等，这对软件的可靠性和安全性提出了更高的要求。

在硬件方面，随着芯片集成度的不断提高，SoC将成为主流。为了满足ISO 26262标准的要求，需要进一步研究和开发更先进的可靠性设计技术，提高SoC的可靠性和安全性。

同时，汽车行业也需要加强对功能安全的重视，不断完善相关标准和规范，确保汽车电子系统的可靠性和安全性，为消费者提供更加安全、可靠的汽车产品。

建议与措施

为了提高汽车电子系统的可靠性，汽车制造商和供应商可以采取以下措施：
1. 加强标准遵循 ：严格遵循AEC - Q100和ISO 26262等标准，确保产品在设计、开发和生产过程中的可靠性和安全性。
2. 采用先进技术 ：积极采用先进的可靠性设计技术，如扫描设计、BIST、IEEE边界扫描设计和ECC等，提高硬件的可靠性。
3. 加强测试和验证 ：在产品开发过程中，加强对软件和硬件的测试和验证，及时发现和解决潜在的可靠性问题。
4. 建立完善的质量体系 ：建立完善的质量管理体系，对产品的整个生命周期进行严格的质量控制，确保产品质量的稳定性和可靠性。
5. 加强合作与交流 ：汽车制造商、供应商和科研机构之间应加强合作与交流，共同研究和解决汽车电子系统可靠性方面的问题，推动汽车行业的发展。

通过以上措施的实施，可以有效地提高汽车电子系统的可靠性，为汽车行业的发展提供有力保障。

措施	具体内容
加强标准遵循	严格遵循AEC - Q100和ISO 26262标准
采用先进技术	采用扫描设计、BIST、IEEE边界扫描设计和ECC等技术
加强测试和验证	在开发过程中加强软件和硬件测试验证
建立完善的质量体系	对产品全生命周期进行严格质量控制
加强合作与交流	制造商、供应商和科研机构合作解决问题