本文章现已有中文版供阅读

车辆 ECU 开发：
功能安全硬件调试

功能安全测试在车辆 ECU 的开发过程中发挥着重要作用。不同阶段的测试有助于开发
人员确保产品符合 ASIL 标准。硬件调试在其中扮演什么角色？综述。

Armin Stingl 著

越来越多的电子控制单元（ECU）被应用到现代汽车中。这些嵌入式系统提供各种功
能，从基本驾驶功能和安全措施到舒适和娱乐功能。根据功能的不同，ECU 中的故障
会对乘客安全产生不同的影响。因此，ECU 按照不同的汽车安全完整性级别 (ASIL) 进
行分类。
例如： 电动转向的 ECU 显然对安全性有很大影响，因为转向失灵可能导致乘客严重受
伤甚至死亡。因此，该 ECU 被归类为 ASIL-D，即最高级别的安全要求。
在开发具有这种 ASIL 分类的 ECU 时，必须从一开始就考虑到安全性。根据 ASIL-D，
开发过程必须符合 ISO26262 标准规定的要求。因此，整个软件设计应遵循适当的开
发方法。所使用的工具可能需要经过鉴定，以证明其适用于这一目的。
然后，在多个阶段使用各种方法对 ECU 和相应的软件进行测试。其中包括单元测试、
系统集成测试和硬件在环测试。根据 ISO26262 的建议，其中许多测试可使用硬件调
试器进行支持，以尽可能接近真实硬件进行测试。

在一个 ECU 中满足多种需求

当今的高性能 ECU 通常不只执行一种应用，而是执行多种应用。这些应用可能具有不
同的功能安全级别。例如，除了 ASIL-D 应用程序外，ECU 还可以执行 QM 级应用程
序（质量管理，即无特殊功能安全要求）。这对软件开发意味着什么？

在这种情况下，有两种方法可以满足 ISO26262 标准的要求： 要么将所有部件都视为
必须满足最高的 ASIL 要求，要么必须保证不受干扰 (FFI)。这意味着必须确保 QM 部
件不会干扰同一 ECU 中的 ASIL 部件（图 1）。

一方面，FFI 必须保证内存的利用率。因此，QM 分区不能破坏分配给 ASIL 分区的内
存。第二个方面是计时和执行。例如，这里必须确保 QM 软件的执行不会阻碍 ASIL 软
件的执行。第三个方面是信息交换，指的是发送方和接收方之间的数据通信中断，例
如插入无效数据或阻塞通信路径。

 

分析源代码

要成功开发 ECU 的安全关键型应用程序，编译器必须具备相应的资质。如果编译器经
过认证，如 TASKING 的编译器工具集，则会有所帮助。
不过，即使是合格的编译器，与所有使用的工具一样，也必须按照 ISO26262 进行风
险评估。每个编译器都有漏洞。所有已知的错误都列在所谓的勘误表中。对于安全关
键型应用，必须对源代码进行分析和检查，以确定是否会受到已知编译器错误的影
响。
大多数情况下，这些工作都是手动完成的。不过，也有一些工具，如 TASKING 的
TriCore Inspector，可以自动检查源代码中所有已知的编译器问题，并生成相应的报
告。这份报告既可以用来调整源代码，也可以直接附在风险评估报告中。
在编译器之后，现在必须检查代码本身是否存在错误，以及其他与 FFI 要求相关的问
题。TASKING 的安全检查工具（Safety Checker）等工具可以在这方面提供帮助，相
当于完全独立于编译器的静态代码分析。开发人员向工具指定系统中所有 ASIL 级别分
区和 QM 分区的预期访问权限，即特定内存区域的读/写和执行权限。然后，该工具会
检查整个源代码，并尝试识别潜在的泄漏，即分区之间可能存在的干扰，例如，由于
不安全、未充分保护指针、全局变量或共享内存的使用而造成的干扰。
这里的假设是，分区之间的隔离不是通过硬件方法实现的，即内存保护单元（MPU）
或 hypervisor。这些方法要么没有在计划中亦或是尚未启用。在后一种情况下，该工
具可帮助排除故障或为 MPU 做好软件准备。软件可以提前做好准备，而不是在 MPU
启用后再调试一个又一个 MPU 异常。而且无需在任何真实硬件上实际运行软件。

 

在目标硬件上进行单元测试

ECU 开发的下一个测试步骤是单元测试。在大多数情况下，单元测试是在源代码级和
主机 PC 上进行的。这意味着要测试的源代码被打包在一个测试框架中。然后可以在此
添加存根（在测试运行期间替代其他代码组件的附加代码，例如模拟尚未实施的组件
或与硬件相关的组件，如 IO）。整个软件包与测试用例一起在主机（如 Windows 或
Linux PC）上编译和执行。结果是一份测试报告，基本上给出了所有测试用例的通过/
未通过情况，通常还有一份代码覆盖率报告。由于测试是在个人电脑上执行的，因此
不包括在真实硬件上的基本执行。测试结果可能不完全相同。
这就是 ISO26262 建议的原因： "软件单元测试的测试环境应尽可能与目标环境一致
"。那么，为什么不直接在目标环境中运行测试呢？
硬件调试工具传统上用于开发和调试驱动程序、电路板/硬件启动、启动过程等。换句
话说，就是用于 "微创"、面向硬件的嵌入式软件开发。除了这些标准方法，如今的硬
件调试器还提供在目标系统上控制软件测试的方法。在这里，调试器通过标准调试接
口连接到实际目标硬件，目的是开发和测试尽可能接近实际硬件的嵌入式软件。这尤
其有助于满足安全要求，即 FFI、执行和定时以及信息共享。让我们来看看一些具体的
测试用例。
在设置单元测试时，被测软件的源代码是针对目标设备交叉编译的，而不是仪器化
的。这意味着原始生产代码将在目标设备上进行测试。

对目标执行测试的实际控制，即下载代码、调用单元（即被测 C 函数）、设置测试输入
向量和读取测试结果，由底层调试器完成，如 TASKING 的 winIDEA 和 BlueBox（图
2）。
与在主机 PC 上执行一样，这里也会生成类似的测试结果： 每个测试用例的通过/失败
结果和代码覆盖率报告。不过，这里的代码覆盖率是根据硬件跟踪记录来测量的，如
前所述，没有任何源代码手段。

为了更深入地了解单元测试是如何在没有代码工具的情况下在实际目标机上执行的，
让我们以 C 函数 "calculateFuelEfficiency "的单元测试为例（图 3）。使用调试器时，
在函数调用之前不必执行整个应用程序。调试器可以将 CPU 的指令指针直接指向函数
入口。按照 C 语言的调用习惯，调试器为函数建立堆栈框架，然后启动 CPU。当需要
存根或数据注入时，例如调用子函数时，调试器会停止 CPU。CPU 不会调用这些子函
数，而是跳过这两个函数，将所需的返回值直接注入指定的 CPU 寄存器。CPU 执行直
到函数返回，调试器在此读取结果值，并根据某些通过/失败标准对其进行检查。所有
这些都可以在不改变生产代码的情况下运行。

故障诊断

在单元测试之后，我们将进行系统级测试，例如在硬件在环配置中进行测试。在这种
情况下，调试器非常有用，它可以向系统注入故障，测试在内存损坏、执行和信息共
享方面对 FFI 的影响。调试器用于对芯片资源（如 CPU 内核寄存器和内存）执行即时
操作，然后检查其影响（图 4）。但故障也可以通过外部接口注入： 直接连接到调试器
硬件和目标系统的 CAN/LIN 和模拟/数字信号附加模块可用于向 ADC 或通过 CAN 或
SPI 连接的外部传感器注入故障数据。

例如，检查 QM 软件的故障是否会对 ASIL 功能的执行产生影响。例如，通过片上跟
踪、实时记录软件中的进程、记录时钟周期范围内的执行时间来观察系统对此类操作
的反应。在此，PC 与实际目标硬件之间的硬件调试器连接至关重要。这意味着 ECU
中安装的处理器上必须有一个相应的片上调试跟踪接口，并将其引出。

时间分析

但是，片上跟踪不仅可以监控软件的行为。由于硬件跟踪绝对是非侵入性的，即对运
行时间没有影响，因此也是时序分析的理想选择。定时测试应作为系统集成测试的一
部分进行。操作系统任务的负载不断增加，自然会影响到整个定时计划，以后将无法
满足关键的定时要求。
在有关安全性和 FFI 的时序分析中，查看时序余量也很有用： 基本上，可以检查整个
软件时序的稳健性。
一个用例展示了调试和跟踪组合工具的功能： CPU 上运行着三个任务：100 毫秒、50
毫秒和 10 毫秒。10ms 任务的优先级最高。在 10 毫秒任务的可运行程序中添加越来
越多的功能，并测量这些功能对 100 毫秒任务响应时间的影响。
通过在可运行程序中添加测试代码来扩展运行时间，就可以毫不费力地实现这样的测
试。调试器可以在测试运行过程中更改测试代码。因此，无需重建软件就能改变可运
行程序的运行时间。
图 5 显示了一个结果示例。绿色曲线显示了 100ms 任务的响应时间与 10ms
runnable 运行时间的对比。假设 100ms 任务有一个时间限制，即响应时间不得超过
85ms：只要 10ms runnable 的运行时间保持在 4.5ms 以下，就能实现这个时间限
制。值得注意的是，在某一点上，响应时间几乎呈指数增长，而此时 CPU 负载也停止
了增长。这清楚地表明，由于系统已经超负荷，操作系统调度已无法真正可靠地工
作。

 

结论

硬件调试器正日益成为一种处理工具--调试器的基本功能找到了它们的常规用途，并辅
以强大的分析功能。
介绍的所有用例和工具都可以结合到持续集成流水线中，该流水线明确专注于软件安
全性测试。因此，可以创建一个测试流程，从静态代码分析到目标系统上的单元测
试，再到调试和跟踪（定时）测试。
当然，在每次提交时运行所有这些测试并不合理。例如，一种策略是只在晚上或软件
发布时运行代码级测试，而在每次软件分支合并到主干时运行集成测试。

 

参考文献

Markt & Technik Trend Guide “Industriecomputer & Embedded Systeme", April 2022, print: https://wfm-publish.blaetterkatalog.de/frontend/mvc/catalog/by-name/MUT?catalogName=MUTSH2202D
Design & Elektronik 08-09/21, Oktober 2021, print: https://wfm-publish.blaetterkatalog.de/frontend/mvc/catalog/by-name/DUE?catalogName=DUE2108D