面向服务的OTA系统 | 从DUT到SUT再到VUT

汽车EE系统工程测试，DUT -> SUT –> VUT

 

汽车电子系统目前正在经历全面的软硬分离开发的变革过程，在这个过程中，会出现大量的新的系统概念，也会对一些传统的系统定义进行新的扩展和强化。本文就一个非常传统的汽车EE系统工程验证的概念DUT切入，谈一下DUT概念的扩展以及相关的系统实践举例。

传统汽车电子验证和测试阶段，被测物大多数情况下都是以DUT的形式存在的，即Device Under Test。Device一般来说都是一个明确的零部件模块（Hardware Components或者Parts module），对OEM来说，Device往往是一个黑盒，验证系统的设计和测试台架的搭建围绕DUT展开，对DUT进行物理接口测试、信号一致性测试、环境测试和压力测试。如果DUT内部的软件模块需要进行质控管理，那往往也是在另一个工程验收维度上进行代码质量管理或者代码认证管理或者研发体系的管理，在台架上针对DUT的测试，不涉及软件交付物。

目前汽车电子SOA化和软硬分离开发变革过程中，一个新的被测物需要被OEM重点考虑，即SUT（System Under Test）。System指的是一个抽象的EE子系统，该子系统给予一个明确的系统输入，子系统就会给出一个明确的输出。这里指的一个EE子系统（严格意义上定义为sub-system或者software component），可以是一个软硬结合的系统模块，也可以是一个可重用的软件中间件模块，甚至可以是一个横跨两个以上分布式计算单元软件服务接口或者功能应用。所以，SUT中的S，很可能是一份软件交付物，但是在工程验证环节则不应该把它看成是软件代码，更应该把它看成是一个子系统的模块。

VUT即Vehicle Under Test，对于汽车来说应该不是个新事物，整车测试其实就是将Vehicle本身变成被测物。但是在车联网和自动驾驶开发环境中，VUT应该会有一些不同的定义，比如车云一体的系统测试中，VUT应该只是一个接入单元，其行驶状态，网络休眠唤醒状态和接入信号强度等，可以是VUT的变量，而车辆的其他结构参数，应该和这种车联网测试环境中的VUT描述没有关系。又如，自动驾驶的测试验证过程中，VUT的描述应该围绕车辆动力系统模型展开，同时车的外饰及结构尺寸也应该是重要变量，而车内其他电子系统以及车的内饰，应该和测试环境中的VUT描述没有关系。

 

从HiL到XiL

 

XiL的定义，在ASAM组织里是有明确定义和规范的，这篇推文里讲的XiL，尽量先回避ASAM的XiL定义，只是尝试阐释一下具体的新架构下的EE工程验证需求。

在下一代汽车架构面向服务的分布式系统中，大家提到最多的是软硬分离和SiL软件在环测试。完全基于虚拟ECU环境，或者其他硬件隔离环境的SiL，是软硬分离开发的最基本需求。但是在实际实操过程中，往往很难做到整个分布式系统的一次性硬件全虚拟化或者全隔离，经常发生的情况，是部分子系统硬件配合另一些虚拟ECU构造一个临时的SiL验证环境，以确保软件的迭代和SUT的验证流程。所以，这里的XiL，是针对理想化的SiL和MiL提出的一种实际的工程开发中间状态的需求和验证环境的概念。

我们通过下图描述该概念：

 

 

上图例举了一个虚拟ECU SiL环境进行SUT测试的概念，而实际在开发和工程迭代的过程中，验证台架不一定能实现。真实的需求可能是类似下图这个样子，部分ECU没有被虚拟化，需要一个真实和虚拟混合的环境来保证SiL的实施。更有可能，在另一个SUT的测试中，由于某些工程上的原因，虚拟和真实ECU的组合又是和上一个测试用例不同。这种满足这种混搭的SiL环境要求的测试台架方案，就是这里说的XiL的概念。

 

 

这篇推文不会重点描述ASAM的XiL和这里提出的XiL共性与区别，只是借用XiL这个缩写，将真实的工程需求进行描述。

 

面向服务的OTA系统

 

谈了以上这些服务化架构和软硬分离开发带来的较新的概念，这里再提供一个实践的案例，进一步阐述对SUT和XiL的理解，即一个服务化接口设计的OTA系统。

这里给出一个简化的基于服务化网关硬件平台的OTA系统。只是为了从工程验证和测试角度来进行一些新的系统定义的实践，所以给出的服务化OTA系统的案例只是一个简化的参考设计，且隐藏了许多车内的和OTA相关的服务化接口（AP、CP、None-AUTOSAR）。

 

 

基于服务化中央网关硬件平台的软硬分离的FOTA系统架构，其负责FOTA执行的软件模块（FOTA OTA Master）部署在中央网关硬件平台上，负责车内FOTA的执行和结果反馈。FOTA OTA Master除了需要调用车内基础服务接口实现FOTA，还需要配合车内硬件的状态逻辑，对FOTA的执行进行管理和诊断。而外网通信模块除了实现IP Router的功能以外，在这个系统里是一个软件接口和协议转换网关的角色。云端接口的API和车内服务化API的设计是不一致的，外网和内网的加密要求也是不一样的，需要进行边缘计算的处理。FOTA in-vehicle Service是个独立的服务化模块，可以独立于中央网关硬件平台提供对云端FOTA指令和算法的解析的服务接口，方便供应商软件解耦。

这样的一个简化了的FOTA系统，由于考虑了软硬分离和服务化接口设计，在工程验证和测试角度，也对SUT和VUT的测试，提出了要求。

 

 

首先是SUT角度，整个系统可以拆分成几个可以独立进行SUT测试的模块，FOTA云端系统是可以脱离车端独立完成测试的（即SUT Container1）。外网通信模块对所有的云端的报文进行了边缘处理，对中央网关和车内系统而言，FOTA服务器和外网通信模块一起，构成了一个脱离车内执行硬件的单独的子系统（即SUT Container2）。该独立子系统的测试，还依赖于FOTA in-vehicle service模块，由于这个模块也是完全平台无关的，所以不影响SUT测试的独立性。

以FOTA Master为核心的FOTA执行单元，和车内可刷写ECU，构成了另一个子系统（SUT Container3），这里为了简化系统的需求，不再进一步细化CP的诊断刷写接口和子系统模块。最后FOTA服务器的可视化部分，也可以是一个独立的测试单元，不同于FOTA的云端功能，可视化部分的需求可能是需要被独立迭代开发的（即SUT Container4），因为很有可能需要和其他IT系统整合和数据打通。

然后我们再来看一下VUT在这个FOTA系统中的实现。

 

 

作为系统多用户触发压力测试的一个环节，FOTA的VUT（Simulator）需要考虑的包括车外网信号强度、外部通信网关的转发性能、FOTA in-vehicle Service和FOTA Master的执行、以及车内系统状态逻辑的各种模拟。而FOTA Master的具体刷写的过程，是可以通过注入Dummy Data的方式来跑通具体的自动化测试用例的，不应该是VUT需要关注的细节。

 

总结

 

OTA系统测试的XiL环境这里就不展开了，简单来说，就是基于不同的SUT的划分原则，在工程开发初期搭建半虚半实，半软半硬的验证环境，确保软硬分离开发过程中软件迭代的缺陷管理和问题追踪，也方便后期为HiL系统降低成本和工作量。

这里就简单介绍了SUT和VUT的概念在FOTA系统上的实践，重点还是在于说明SUT的概念在软硬分离和服务化架构中如何具体落实。该系统由艾拉比和怿星科技共同研发，应用于面向服务的OTA系统测试。