下一代EE架构的底盘系统测试台架设计方案

‍‍01.前言

底盘系统存在大量连续非线性特性的控制逻辑，同时对整车安全有着至关重要的作用，在实车测试(特别是实车动态性能测试)之前更好更准确的进行台架级测试，能大大降低实车测试风险和成本，所以其系统功能/性能测试历来是一个较为复杂且重要的课题。

现如今，随着各个主机厂在底盘开发业务上不断延伸，以及EE架构的不断升级，现有的测试系统越来越难满足新的需求，主要体现在：

1、底盘内各个系统功能的关联性越来越强，底盘域控单元的开发已经在各个主机厂启动，传统的单一HIL测试台架（悬架/制动/转向）无法完成底盘域控功能的相关测试。

2、各个主机厂对车辆的功能迭代速度的比拼进入了快车道，要求软件能够敏捷开发/交付，从而需要构建CT体系以快测试来完成软件的验证，但现有的大部分HIL测试台架，自动化测试覆盖率不高，无法达成这一要求。

3、智驾等技术的不断成熟，导致与之相关的底盘系统要配合完成功能实现，越来越多的主机厂希望这部分软件或是所有底盘软件进行自主化开发，以实现软件的快速迭代以及核心技术掌控，从而对测试台架带来了软件开发过程中的debug/仿真需求。

4、新一代EE架构下，底盘系统强人机交互的功能往往被剥离并上移到基于SOA的域控单元。传统的HIL台架已经无法完成。

为了应对上述问题，底盘系统需构建了新一代的系统测试台架，在解决上述问题的同时，在其它方面也带来提升（具体见后续能力详解）。

02.系统设计方案

2.1、测试范围/目的

底盘系统测试台架的主体为硬件闭环设备+车辆动力学模型+测试工程，主要作用为：

①、支持广义全自动化测试；

②、包含平台化的设计概念；

③、全程支持软件的自主化开发；

④、支持部分驾驶感受主观评估测试；

2.2、设计方案

台架分为：制动系统测试台架、转向系统测试台架、悬架系统测试台架三个部分，同时三个部分可以通过硬件耦合+底盘系统测试工程形成底盘系统测试台架，从而共计四套测试系统。如下所示：

图1

每个系统分为三个层级：

a、软件级：用于验证内部逻辑的软件闭环

b、信号级：通过硬件仿真设备达成硬件仿真闭环

c、系统级：控制机械负载施加反向激励及模拟驾驶员控制输入从而达成系统闭环

图2

其中：

每个系统都支持软件闭环；

每个系统都支持硬件仿真闭环；

每个系统都支持系统闭环；

三个等级的测试，不会对所需组件进行严格区分，比如系统级测试也会使用部分仿真设备资源；

2.3、注意

①、目前国内少有成熟的悬架系统（特别是空簧系统）动力学闭环仿真模型可借鉴，开发难度较大，需要和整车实际情况进行反复对比，以拟合出尽可能相近的特性曲线。

②、本文并未提及任何关于完成此台架的实现手段（硬件方案、软件方法等），仅阐述新一代台架需达成的目的及实现该目的方法论。原因在于：不同供应商/主机厂对于系统测试台架的定位和赋予的职责使命不尽相同，从而需要不同的软/硬件方案配合完成其目的。

③、部分通用模块可以委托第三方开发，但涉及功能/算法的部分，必须具备自己开发的能力：

编制自动化代码的过程可以加强对功能的理解，反向校验功能设计的同时，提升团队能力；

复杂逻辑case的实现，需要对功能的深度理解，如果委托第三方，需要花费很多时间阐述要求；

很多测试case的验证方法，强依托于实现的逻辑，如果将这些逻辑开放给第三方，有泄密的风险；

为了更好地支持软件开发，系统台架应具备实时调整测试case的能力，自己具备相应能力，可以大大降低失控风险；

03.底盘系统测试台架能力详解

3.1 支持广义全自动化测试

区别于狭义的自动化测试的概念(这是老生常谈的议题，这里不再继续详细展开)，此底盘系统自动化测试台架，不仅包含测试用例的自动化执行，更着重于实现各个环节的测试任务一键式达成，具体体现为：

① 支持实车问题的自动化注入

偶发性的实车问题历来为工程师所头痛，其随机性、无序性等特点给工程师带来了很大的分析难度。一个有效的解决此类的问题的方法是在台架上复现此问题，从而可以通过单步Debug的方式快速锁定问题。

本系统在导入实车数据后，通过多次逼近的方法不断快速缩小实车信号和仿真信号的时间差并控制在10ms内，同时利用过程预判的机制，将台架和实车的物理量值偏差控制在1%以内，从而有效复现故障场景，以期复现故障，加速问题解决。

② 测试工具链的全栈打通

打通测试上下游工具链，达成一键式自动化测试，可以大大减少人为干扰和测试时间，提高测试效率和准确度。具体细节如下图3所示：

图3

其中需要注意的是：

a、本设计中自动化工具链的起点为被测软件上传到了共享盘，在这之前关于软件的自动化加密、压缩等暂不考虑；

b、通过远程控制启动测试以达成暗灯测试，当然也可以通过检测软件是否更新来自动触发测试进程；

c、项目配置文件中，应包含被测内容的可选范围，以应对不同的测试需求，比如：新软件中仅仅软件版本号发生了改变，测试时不应该加入故障注入等测试项目（具体见本3.1章节第⑤条）；

d、关于测试结果：测试报告为自动生成；时刻录取过程trace及控制信息；问题上传到问题管理系统时，应附带trace并指出异常出现的具体时间；

e、问题出现的频次、概率等的信息统计，由问题管理系统进行维护，这里不进行阐述；

③ 输出结果为连续性特性功能的自动化测试（动态性能自动化测试/仿真）

底盘域的一些动态控制功能，其表现出来得输出特性多为连续非线性。常规的测试手段无法准确判定其是否达成设计目标，基于此，我们采取下述方法来完成验证目的：

a、采用多点采集/判断的方式，对连续性执行结果进行多次仲裁；

b、将采样点的时间及输出有效值范围进行参数化处理；

c 、通过百分比或是绝对值的方式限定有效值双死区范围；

d、测试/仿真的结果能够做横纵向对比，这一点尤为重要！

④ 支持ECU 特有测试用例的自动化测试

这类测试往往基于被测单元的固有特点，很难通过其它手段（集成测试/实车测试等）测试，比如：功能全部激活时所表现出的最大CPU 使用率、Bus load >95%时对高功能安全等级的功能的影响等。

⑤ 被测单元的测试范围有可选择性

不同测试目的下，被测单元的测试范围也不同。整个系统测试工程应留测试case的选择配置选项（如下图4示例），或是通过的测试类型进行配置化管理（如下图5示例）。

图4          图5

同时，因为底盘系统的ECU都会进行大电流控制，这种大电流控制的测试时间往往受限于ECU/硬件的散热性以及其固有的器件保护机制。基于此点的考虑，设计者需要充分考虑为提升测试效率而做出的测试case选择性配置需求。

⑥ 测试case代码的自动生成

理论上讲，测试case代码的自动生成是自动化工具链的一环，此处把此条目再次单独阐述，除了其在整个工具链上下游位置关键、任务量最大外，还尤为需要注意下述几点：

a、区别于一些BSW等的共性测试，ECU功能测试需要开发者对各自产品功能非常熟悉，以能够较好完成case的实现及平台化的设计；

b、开发者应该根据实际的开发情况，制定测试case的录入规则，否则脚本语言无法识别无序的case描述从而无法达成自动代码生成；

c、因为底盘系统的部分性能测试步骤比较复杂，模块化、图形化的编程方式有时很难完成此种case的测试实现，这里推荐使用coding的形式来完成自动代码生成。

⑦、参数的自动导入

a、不同项目/平台有着不同产品特性差异，需要通过产品特性参数来达成可配；

b、因为上述不同的特性差异，测试时同样需要调整测试参数来界定有效输出范围；

这两种参数需要在测试前由产品工程师及测试工程师分别完成，完成后自动导入到测试系统完成测试。

⑧、支持底盘域联合功能测试/底盘域控制器功能测试

3.2、平台化的设计概念

由于底盘系统测试台架一般投入较大、开发周期较长、开发复杂度较高，通常情况下需要尽可能考虑让台架承接更多的项目/平台测试需求等，具体如下：

①、支持底盘域联合系统联合测试

一般情况下，供应商仅能够提供底盘系统内单个子系统的开发/测试能力，所以底盘域控功能的测试工作一般由OEM完成。目前极氪的整个底盘系统测试台架的设计采用由三个子系统组合完成的方式实现，具体为：悬架、制动、转向的系统测试台架可以单独运行，提高台架的适用效率。当有底盘域联合系统测试需求时，将三套系统台架进行通讯连接，并使用基于底盘系统测试的工程，即可完成该测试，以满足底盘域功能测试的需求。

②、平台/项目/车辆配置间差异化需求的解决方案

a、开发BOB工装，完成不同ECU接口定义转接；

b、开发虚拟网关，完成不同通讯定义的转发，特别是针对基于中央超算的新一代EE架构，需要开发基于以太协议的仿真网关，并开发上移至中央超算的逻辑功能的测试case，来完成最终的测试；

c、台架保留更换ECU及相关执行机构的能力，以应对不同项目采用不同供应商的产品带来的差异；

d、测试工程通过导入不同配置参数列表，以应对差异化的测试需求；

③、软件闭环和硬件闭环可快速解耦

由于本系统测试台架承担了支持软件/算法自研的任务，所以要求硬件仿真闭环可以和系统闭环间迅速解耦，以便单独使用硬件仿真闭环系统（或称为：桌面级HIL/信号级HIL）来支持软件的快速调试/仿真。

④、提前预留动力等其它域的扩展

a、台架预留动力域硬件接口，特别是通信接口；

b、梳理和底盘域有交互的其它域的相关功能，并进行case设计，以提前识别相关需求；

c、完成动力等域的动力学模型搭建；

3.3、全程支持软件的自主化开发

底盘系统逻辑复杂，底盘电控系统的主流供应商一般为国外企业，其对国内OEM形成技术性壁垒。为了打破此种状况，极氪底盘电控团队正在基于下一代EE架构进行底盘全学科及底盘域控的软件/算法自主性开发。作为开发中重要的一环，系统测试台架可以有效的支持整个开发过程。具体为：

①、辅助完成功能安全的设计

对功能安全case进行仿真验证，辅助验证case设计是否合理。

②、功能需求设计的检查/校验

测试case的设计遵从正确输入时功能达成、异常输入时输出表现合理、故障注入时结果在预期内的原则，来覆盖所有功能要求。此原则下，测试case设计过程会对功能需求内容进行反向检查/校验。

注意：售后或下线检测功能等也是功能需求的一部分，不应该被忽略。

③、特殊功能/算法的台架验证

作用主要体现在：

a、提前于造车计划，进行功能、性能的初步验证；

b、危险case的先期验证，比如：100km/h速度下大弧度转弯时，底盘各系统对车辆防侧倾的作用占比及翻车风险评估；

c、ECU参数的初步标定；

④、包含手动测试界面，用于软件/功能单步调试

手动测试工程包含所有输入输出的控制按钮以及对应内部逻辑处理，以确保可以手动进行功能的单步调试。

支持范围：转向/制动/悬架子系统，或是底盘域控制器系统。

⑤、动力学仿真模型可复用于SIL/MIL测试

以用来加快功能/算法开发进度。

3.4、支持部分驾驶感受主观评估测试

如题，本系统可以支持譬如踏板感、方向盘手力等主观功能的测评。

04.  总结

随着国内汽车工业的发展，主机厂在底盘电控开发中的责任占比越来越高。为了有效把控软件开发进度，提高软件交付质量，系统测试模块除了考虑常规功能的自动化测试外，亦应主动承担更多的任务：努力推动供应商/自研团队基于CD/CI/CT来实现软件的迭代和交付、支持问题分析、推动问题解决进度等。

尤其在底盘领域，为了使主机厂在电控开发上占据更加主动地位，达成更快速的功能实现，更应该积极进行掌握XYZ轴向控制原理，建立用于算法动态仿真的动力学模型等等，以支持主机厂的复杂功能/算法自研工作。

基于上述目的，本文抛砖引玉，阐述基于极氪下一代EE架构的底盘系统测试台架设计方案。

底盘电控系统的自主开发其路漫漫，希望测试同事能从本文得到一些启示，找准各自在软件开发的定位，并依此 “上下而求索”。

编辑：黄飞