快资讯丨车载TBOX嵌入式设备软件的功能测试

本文来源：鉴源实验室

(资料图片)

/ 导读 /

我们聚焦到具体的ECU测试上来（以车载TBOX为例），因为相比车辆其他电子零部件，车机系统和Tbox涉及的功能模块和上层应用多一点。当然我们在文档中可能不仅仅只描述Tbox相关的内容。

Tbox简介

Tbox(Telematics Box)是汽车座舱系统中的一个ECU，物理外观上是一个方正的盒子，通常会有线束接口、HSD接口、通讯和导航天线接口等。软件上Tbox一般会基于Linux操作系统如Ubuntu、CentOS等，配合上层软件进行深度定制。而车机系统目前一般选择Android进行深度定制。

Tbox的作用是作为车辆的网络出口，将独立的车辆网络环境跟互联网进行连接，促进了现在车联网的形成。综合起来看，Tbox是带通讯功能的盒子，内含SIM卡，一般是物联网SIM卡，与这个盒子配套硬件还有GPS天线，4G天线等。

当前已经有主机厂和大的零部件供应商在研究一体式的车机系统，将传统的车机和Tbox合二为一，从而取消独立的Tbox物理设备。

Tbox的通讯

Tbox通常挂载在诊断Can上，且诊断CAN一般只有Tbox一个电子控制零部件。

Tbox通常内部有MCU和MPU两个控制单元，相互之间的通讯一般基于UART协议。

Tbox的外部系统通讯一般有以下几个部分：

（1）基于4G或5G通讯模组的上网通讯以及卫星导航定位，这部分都是集成移动通信供应商标准模组，主机厂或Tbox零部件供应商自定义程度较低。

（2）Tbox与主机厂TSP（运营商服务平台）云端平台间通讯，通常使用主机厂自定义的通讯协议。

（3）新能源车基于国标GB/T 32960规范要求的直连和转发通讯。

（4）Tbox跟车内其他零部件间的CAN或车载以太网通讯。

（5）Tbox跟车机娱乐系统间的HSD（高速数据）连接，基于IP网络socket通讯。

（6）Tbox跟其他设备间的专用通讯，需要看项目具体设计，如跟SRS（安全气囊）硬线连接通讯等。

Tbox的功能划分

从上个章节我们可以看出Tbox本身有多个跟其他系统的交互模块，这些模块基本都会对应不同的上层应用，此外还有Tbox维持本身正常工作的功能设计模块等等，总体情况下Tbox可以有以下大体划分：UDS诊断功能、电源管理功能、注册激活功能、车况上报功能、报警上报功能、安防报警功能、大数据上报、远程控制、娱乐主机功能、Bcall功能、电子围栏、蓝牙功能、无线通信功能、导航定位功能、新能源国标上报、泊车测试、FOTA功能等等。

对于这么多功能模块的测试设计，我们可以依据的文档还是比较多的，直接关注和应用的文档大体上有：TBox产品功能技术规范（不同主机厂的命名可能不一样）、Tbox项目的诊断规范、Tbox与TSP后台通讯技术规范、Tbox功能信号表（不同主机厂的命名可能不一样）、Tbox与娱乐主机USB通讯技术规范、整车FOTA功能技术规范、自动泊车功能技术规范等等。

主机厂各个技术规范的编制过程关系大体如下图所示：

Tbox测试

汽车零部件包括Tbox在内，从设计研发到整车商用发售这个过程中，大体会经历以下几个测试阶段：零部件单元测试、子系统集成测试、整车系统测试、功能专项测试，其中功能专项测试一般与前面的常规测试并行，基于子系统的成熟度，最早在集成测试阶段开始，最晚在整车系统测试阶段开始执行。

4.1 零部件单元测试

Tbox的单元测试一般从A样正式交付后开始进行，到释放C样给OTS造车开阀结束，主要对设备的基本功能进行模块测试。单元测试阶段各个零部件均处于研发阶段，子系统零部件之间的接口和功能测试受到条件限制，测试重点通常着眼于对零部件自身功能实现的保证。

在单元测试阶段Tbox功能和接口测试会占用单元测试的很大部分时间，特别是电源管理和网络诊断两部分。直接关系产线电检测试的成功与否，影响EP造车和OTS造车质检反馈。

单元测试阶段通常是在测试台架上进行，单元测试阶段Tbox的测试内容大体有：

白盒测试在研发质量体系对代码的编码规范有约束要求的情形下，通常在从项目开始就要进行代码的静态规则检测，在项目功能安全设计作等级要求时，通常还会对代码进行结构覆盖度测试，即动态代码测试。常用的工具通常有：Helix QAC、SmartRocket TestGrid、LDRA TestBed等。

功能测试在本阶段发布的版本质量要求上，零部件所有重要功能都必须实现，允许存在故障，但不能是致命级别导致设备无法使用的故障。Tbox在单元测试阶段的功能测试通常可以和接口测试一起执行，这样可以有效减少重复的测试工作，像是诊断、车况和报价信号等的正确性测试之类。对于功能比较独立的测试类似注册激活、电源管理、通讯模块AT测试之类在测试过程中都存着循环迭代的过程，建议在做测试计划时通过功能测试+回归测试的方式提高效率，在所有故障和功能在回归测试中都验证良好的情况下，再执行全功能覆盖遍历的功能测试。

接口测试零部件的模块间接口和零部件对外的设备接口测试在单元测试阶段完成，通常这个接口测试比较简单，Tbox在进行内外部接口测试时通常会通过tester模拟发送各种信号，测试人员验证Tbox收到各种信号的反馈是否正确，这里的接口指的是本文前面提到的所有通讯接口。

4.2 子系统集成测试

Tbox的子系统集成测试一般从OTS造车交付开始进行，到释放版本给PPV造车开阀结束。此阶段零部件硬件开发基本冻结，集成测试阶段的目标是确保子系统中各零部件工作正常，各功能在所有零部件间的实现可靠、正常。尽可能发现和解决问题，为PPV（G4）开阀造车做好充分准备。

在子系统集成测试阶段已有实车可以提供测试，相对于子系统的用车需求部门数，实车数量是较少的，所以这个阶段子系统硬件在环的台架测试工作量通常还是大于实车工作量的，一般情况下都是硬件台架验证完成确认问题修复后，才会到实车进行大规模验证。

这个阶段的零部件测试已经不再聚焦零部件内部了，而是把重点放在子系统内部的各个零部件间接口和功能的验证，所以在子系统内其他配合零部件状态良好的情况下，功能专项测试就此开始，如远程控车、自动泊车、整车FOTA、新能源车的国标考试内部验证等等。

在集成测试的过程中，无论是专项测试，还是实车或台架测试，所依据的技术基础都是子系统内不同零部件间的各个通讯协议，实际项目中特别需要注意的是Tbox和其他零部件在细分上不是一个研发项目组控制，这种情况在不同零部件间普遍存在，就会容易导致一个问题，零部件之间的通讯协议是不停迭代的，而零部件的软件研发版本也是基于协议在迭代，这样就会出现不同零部件释放的用于子系统集成测试的软件版本，依据的通讯协议版本不一致。所以子系统集成测试，或者专项功能测试时版本的基线特别要注意，这也是我要强调的在实际项目中Tbox联调时遇到的项目管理问题要比产品本身的技术问题多，因为整车系统中所有零部件的上网功能都是通过Tbox来完成的，对接的配合件比较多。

相对于实车环境的复杂和存在的大量干扰因素，台架测试环境相对比较干净，Tbox的台架测试拓扑图如下：

4.3 整车系统测试

Tbox的整车系统测试一般从PPV造车交付开始进行，到出版本给PP造车开阀结束。正常情况下在这个阶段Tbox以及其他零部件状态都比较好（项目管理把控弱，质量失控的除外），所有零部件的重大问题都已完成修复，在此阶段的工作就是通过大量的实车测试，发现异常场景下的问题，以及一些功能优化调整。

需要特别注意的是在这个阶段最好做到所有已知问题修复清零，一些主机厂质量管理和考核体系中，PP阀点后车辆路试组发现的问题会归属于工程问题，不再是简单研发故障，对于考核绩效会有影响（质量绩效管理不是这样的当我没说）。

整车系统测试的重点在于大量的实车测试，对于Tbox来说重点在于实车特殊测试场景的设计，如隧道、高架、山地、地下、高楼间等等，注意导航信号的准确性，2G、3G、4G、5G不同网络间的信号切换等等。

总结

对于Tbox的测试我们从整体上按照常规做法在各阶段完成对应的测试工作，就可以保证产品在各阶段的应有质量。

目前整车新功能新技术的发展很快，新能源车很多概念炒作的比较火热，但是实际在量产车型上，各主机厂的设计一般相对没有采取激进的方式，新的零部件和功能的设计都是建立在可靠性的基础之上。Tbox也同样如此，对于主机厂而言，Tbox的技术已经相当成熟，新车型的Tbox一般都是进行项目的适配性开发，我们测试所要关注的重点通常都在项目子系统其他功能配合零部件的联调进度上，Tbox本身测试设计和执行难度不大，所以测试工作不能仅仅关注测试本身，测试项目管理相关的事情同样非常重要。

- End -

免责声明：

凡本公众号注明“来源：XXX（非智车科技）”的作品，均转载自其它媒体，转载目的在于传递和分享更多信息，并不代表本平台赞同其观点和对其真实性负责，版权归原作者所有，如有侵权请联系我们删除。

关键词：单元测试集成测试