随着我国汽车产业网联化的快速发展，车载网联系统的复杂度不断提升，新的技术、设计思路和应用服务持续引入。传统验证方法大多基于系统集成及研发流程角度进行代码级测试、子系统级测试、集成及系统级的测试，难以全面覆盖和适应设计侧的不断发展。为应对以上挑战，建立以用户体验和产品性能为中心的验证体系，本文提出了一种基于架构特性的验证方法。该方法通过分解车载网联系统的技术架构，提取系统特性，针对性地制定了系统设计、产品视角以及主观体验三个方面的测试方案，形成了一种体系化的网联系统验证框架。
0 引言
近年来，基于典型的V 字形开发流程[1]，车载网联系统的设计侧在持续发展。
在网联应用维度，内容和服务的丰富度不断提升，生活、娱乐和出行等第三方生态持续导入；在人机交互维度，语音、视觉、手势甚至生理特征等新方式持续加入，逐步迈向多模态的人机交互时代；在零部件技术维度，芯片架构不断优化，算力不断增长，虚拟化等技术催生一芯多屏、AR-HUD 等座舱域的发展，多核异构、SOA 等技术持续提升系统功能集成度、软硬件复杂度以及计算类型的多样性；在通信技术维度，GPS、蜂窝网络（4G/5G）、短距通讯（Wi-Fi、蓝牙、NFC、UWB 和Zigbee）以及LTE-V 等无线通讯技术持续引入，车内有线通信技术也从原有的LIN、CAN、CAN-FD、FlexRay 和MOST 等向更大带宽的车载以太网进化；在整车E/E 架构维度，逐步从分布式、域集中向Zone+计算平台的中央集中方向演进；从法律法规维度，国家及行业层面陆续发布了关于设计规范、数据安全、功能安全、网络安全和OTA 升级要求等相关规定。
但在验证侧，对应的验证手段存在一定程度的滞后和缺失，并面临着诸多系统性的挑战。本文着重从技术架构角度，针对现存问题及挑战，建立了一套系统性的验证方法，以应对不断发展的用户需求和技术进步。
1 研究目的
1.1 应对场景泛化及交互复杂度提升的挑战
车载网联系统的产品竞争力集中体现在网联服务、应用场景以及交互体验等方面。为提升用户体验，目前系统的功能和服务生态愈加丰富，应用场景逐步由车内向车外拓展，交互体验也从单模向多模态发展。这些对于系统的验证方案、方法和评价都提出了更高的要求。尤其是如何从传统的关注系统性能参数、可靠性、耐候性及电磁兼容性（EMC）等偏客观测试项，拓展到与用户使用的实际感受相关的考察项，需要测试团队结合更多的跨学科技术以及更多的测试技术创新。
1.2 应对技术持续发展的挑战
车载网联系统是多技术融合应用的产物，包括高算力芯片、操作系统、人工智能、大数据、云计算、导航定位、音视频编解码、计算机视觉以及4G/5G 和车载以太网等通讯技术，涉及到汽车电子、互联网、ICT、消费电子和芯片等众多产业领域。除汽车领域本身以外，不同的领域具有不同的设计标准和验证方法，这对网联系统验证体系提出了更多的跨行业要求。尤其是如何既保证符合法律法规及准入要求，又能在成本和质量方面进行控制，需要开发及测试团队在设计和验收上制定合理的标准。
1.3 应对设计方法及理念进步的挑战
近年来，网联系统的概念和范畴在不断扩大，软件上从信息娱乐、远程控制到互联网生态再到智慧出行和智能交通；硬件上从分布式的娱乐主机、组合仪表到座舱域控再到舱泊一体甚至舱行泊一体。此外，研发理念从以产品为中心向以用户为中心过渡，与之对应的软件定义汽车、用户共创、SOA（以服务为中心的设计概念）、千人千面和常用常新等设计理念被引入到网联系统开发体系。这些均倒逼测试理念需要与时俱进，建立与之对应的全面验证流程和标准体系。
2 研究目标及思路
2.1 目标
架构设计在设计流程上处于前期阶段，是系统效用和表现的重要基础。业内通常从2 个维度进行该系统的设计。
首先，该系统从技术维度可分解为三纵六横的技术架构[2]。纵向可分为车舱平台、云平台和拓展设备，其中车载平台包括网联系统主机、屏幕和T-BOX（车载网联通讯终端）等车端设备；云平台包括远程控制平台、OTA（远程升级）平台、内容和服务平台、数字钥匙平台以及远程诊断平台等；拓展设备包括即插即用的硬件生态设备，如记录仪、香氛和K 歌设备等。横向则可分为人机交互关键技术、系统与零部件关键技术以及基础支撑关键技术（图1）。
图1 网联系统的三纵六横技术架构
其次，该系统从系统拓扑维度可分解为“云-管-端”框架。其中，云侧包括车厂自建云、第三方生态云及云控平台等；端侧包括车内的网联系统计算平台以及车载通讯终端等，也包括用户手持设备（如智能手机、智能手表和NFC 卡等），同时也涵盖RSU 路侧设备以及智能外设等。管侧有车外无线管道和车内有线管道，其中车外无线管道包括远距通信的蜂窝网络、中距通信（如LTE-V/5G-NR）以及短距通信（Wi-Fi、蓝牙、UWB和NFC 等）；车内有线管道包括CAN、USB、LVDS、车载以太网甚至光纤等（图2）。
图2 网联系统的云-管-端拓扑架构
综上所述，网联系统架构复杂，表现出功能模块多、通信链路长、接口开放度高、技术跨域且难度大等特点。如何构建起对应的验证测试体系是行业的当务之急。本文研究的目标为化繁为简地建立起以产品性能和用户体验为核心的测试验证体系，并能够横向覆盖全功能场景，纵向覆盖各专业领域。该体系表现为：首先，结合用户需求及研发效率，从系统设计、产品表现及用户体验角度对系统架构特性进行抽象（表1）；其次，针对架构特性和技术特点制定对应的测试策略。
表1 网联系统架构特性表
2.2 网联系统的架构抽象
2.2.1 系统设计角度的架构特征抽象
（1）可靠性：可靠性是网联系统的基础。系统在功能方面，设计与实现需保持一致性，系统能够按照用户需求和既定功能进行正确的操作、响应和处理；在时间方面，任务不出现延迟或超时的情况；在数据方面，能正确存储、传输和处理，保证其准确和完整。
（2）稳定性：整车的电磁环境苛刻，用户使用场景多样，且涉及与手机、智能外设及通讯基站等设备的连接，因此要求系统在不同工况下能持续可用，功能上不能出现卡死、黑屏或中断等严重问题；性能上运行保持较好表现，不出现性能下降的情况。
（3）兼容性：网联系统对内需保证不同硬件平台、底层软件、操作系统及第三方软件有良好的互通性和互操作性；对外需与扬声器、MIC 和屏幕等车载外设及各品牌型号的手机、智能外设甚至网络环境等保持良好的交互和通讯。
（4）移植及复用性：为保证系统持续迭代及平台化的规模应用，跨车型、跨整车配置及跨硬件平台的移植及复用能力对于网联系统至关重要，故架构设计上需考虑模块化的设计、标准化的接口、代码重用性及技术路线的标准化。
（5）配置灵活性：在软件定义汽车及SOA 设计理念的指导下，网联系统应具备一定的灵活性。在研发层面，应能快速兼容不同硬件、配置以及车型差异；在生产阶段，应能适应不同产线工具及标定场地的差异；在用户层面，应能通过软件的配置和参数标定来满足用户个性化需求，同时也能通过开放平台和用户共创工具，来支持个性化的场景。
（6）拓展便利性：网联应用和服务丰富度是网联系统重要特征[3]。目前业内通常以OTA 升级[4]、应用商店或小程序商店等方式进行功能和服务的更新和拓展。网联系统应能简单、快速以及低风险地进行拓展，且过程中应易于集成、部署、升级和监控。
2.2.2 产品视角的架构特征抽象
安全合规性：网联产品应按产品定义和销售区域要求，满足相关的安全标准和法规，包括相关上位法（各国家地区法律）、工业和信息化部、国家市场监督管理总局、全国汽车标准化技术委员会（简称汽车标委会，NTCAS）、国际标准化组织（ISO）、美国汽车工程学会（SAE）及联合国欧洲经济委员会（UNECE）等关于数据安全、功能安全、信息安全、设计验证以及OTA 升级的相关要求。
智能性：网联系统的智能化具体表现在交互的智能化及网联生态泛化。在交互智能方面，网联系统应能更好地感知人类的需求和行为，根据用户的需求和偏好自适应，让用户享受到更个性化的服务。网联生态泛化方面，结合车型定位，系统应具备更多合适的场景化功能，系统可不断升级和扩展，并能更好地与各类服务及设备进行连接和协同。
2.2.3 用户体验角度的架构特征抽象
（1）高效性：网联系统承担着人车交互的媒介。人与系统间信息传递和反馈的效率至关重要，在操作上应具有足够高的绩效，包括支持交互的程度、操作速度和准确度等。整体设计上应让用户更易感知、学习成本足够低，交互逻辑易于理解。
（2）愉悦性：用户在使用过程中的情绪感受也非常重要。网联系统应该能从感官层面和心理层面给用户提供足够的舒适性和满意度。用户对于系统信任与否、是否具有趣味性和认同感是提升舒适性的重要指标。用户的满意度也考验着系统在功能和操作方面满足用户预期的能力。
2.3 基于架构特性的验证方法
针对以上架构特性，设计对应的测试手段和方法并进行体系化验证（表2）。
表2 基于架构设计的验证内容
3 基于架构特性的验证体系详述
3.1 可靠性验证
3.1.1 测试方法
（1）单元测试：针对车载网联系统中的每个模块进行测试，验证其功能是否与需求保持一致，能够正确地进行操作和处理。
（2）系统测试：通过台架、HIL 及实车动静态来验证系统的功能与需求的一致性，且能在规定时间内完成任务，不出现延迟或超时。
（3）整车路试：路试搭载可结合各车厂现有整车及零部件的测试要求，进行包括多种路面、温度及里程等方面的测试，以综合考察系统性能表现和耐久表现。
3.1.2 测试指标
（1）功能：反映系统功能完成度、BUG 率以及问题等级等，考察功能的设计符合性。
（2）时效：反映系统冷启动、休眠唤醒、界面切换、应用加载以及操作控制等方面的响应速度。
（3）数据：反映数据准确性、处理效率及不同网络环境和工况下的表现等。
3.2 稳定性验证
3.2.1 测试方法
（1）压力测试：在高强度、高并发或特定场景下对系统进行测试，可通过自动化设备进行。如利用Monkey 测试等来验证系统在连续、不同工况下的可用性。
（2）负载测试：对系统进行大负载测试，包括连接手机、外设和应用全开等场景下测试，验证系统在不同负载下的稳定性。
（3）容错测试：在系统中模拟用户误操作来人为制造故障，包括快速连续操作、非正常应用切换等。同时，也测试系统在各种异常情况下的稳定性，如严苛EMC 环境、网络中断、蓄电池欠压或通讯线束故障等。
3.2.2 测试指标
（1）连续性：反映系统在不同工况下的连续工作时间和持续可用能力。
（2）性能：反映系统在不同负载和工况下的性能表现。
（3）容错：反映系统在出现故障或错误的情况下自动恢复能力。
3.3 兼容性验证
3.3.1 测试方法
（1）单元测试：对系统中的每个模块进行测试，验证各模块的兼容性，包括输入、输出和边界条件等。
（2）集成测试：验证模块之间的兼容性，包括数据传输和功能调用的正确性。
（3）系统测试：验证系统的兼容性，覆盖整个系统的所有功能，并需考虑变量的覆盖性，如硬件芯片不同的架构和指令集、操作系统不同的版本、手机不同品牌或同品牌不同的型号以及通讯协议的不同版本等。
3.3.2 测试指标
（1）向下兼容性：反映系统是否能与不同硬件平台、底层软件及相关的驱动程序进行兼容，包括不同的接口和协议等。
（2）向上兼容性：反映系统与不同的操作系统、应用软件及服务的兼容性，也包括不同的编程语言、编译器及开发环境等。
（3）数据和功能互通性：反映系统与外部设备的兼容性，保证数据和功能的互通性和互操作性。
3.4 移植及复用性验证
3.4.1 测试方法
（1）单元测试：对各模块进行边界测试和异常测试，验证系统的容错能力和鲁棒性。
（2）集成测试：验证模块之间的接口是否清晰明确，是否能够方便地进行组合和拆分。
（3）系统测试：测试系统能够在不同的车型、整车配置及硬件平台之间进行移植和复用。
3.4.2 测试指标
（1）模块化设计：反映系统模块化设计程度，验证系统各模块的可重用性、可移植性、模块间接口的清晰性以及组合和拆分的便利性。
（2）接口标准化：反映接口和协议的标准化程度，重点关注接口的调用方式、函数命名和参数设计等方面。
（3）代码重用性：反映代码在不同产品、环境中移植和复用程度。
（4）技术标准化：反映系统采用技术的通用性，以规避不可控的风险，减少试错成本。
3.5 配置灵活性验证
3.5.1 测试方法
（1）可配置性测试：针对操作系统、应用程序、外设及各平台的可配置范围和便利性测试。
（2）生产环境适应性测试：测试系统在不同的产线工具和标定场地下的适应性。
（3）开放平台测试：测试系统在开放平台和用户共创工具上的便利性。
3.5.2 测试指标
（1）可配置性：验证系统可配置的内容、程度及方法，包括配置的便利性和自适应性等。
（2）生产环境适应性：验证系统在不同的产线工具和标定场地下的适应性，确保不同生产环境中系统可正常上线及出厂。
（3）开放平台能力：针对开发者关注开发社区、工具、环境和版本发布等，包括API、SDK 及插件的兼容性和扩展性等指标；针对用户关注交互接口、界面及响应速度等。
3.6 拓展便利性验证
3.6.1 测试方法
（1）模块扩展测试：通过添加新的功能模块、接口等方式，对系统的拓展能力进行测试。该测试方法可以验证系统的拓展性和灵活性。
（2）接口扩展测试：通过扩展接口，对系统拓展能力进行测试，包括其兼容性和扩展性。
3.6.2 测试指标
（1）拓展性：反映系统的拓展能力，包括模块类型、功能数量和接口类型等。
（2）便利性：反映系统拓展便利性，包括拓展方式、复杂度、工具和环境等。
3.7 安全合规性验证
网联系统的安全合规性验证是为了确保系统符合相关的安全标准和法规，表3 所示标准和规范已针对设计和验证方法等做了相关规定。各企业可根据自身产品定义，制定对应的合规策略。
表3 网联系统安全性相关规范一览表
3.8 智能性验证
3.8.1 测试方法
（1）交互智能性测试：测试系统在人机交互上的表现，如语音、手势和触控等交互方式，尤其是交互的准确性、个性化、界面的自适应性及多摸态协同等方面。
（2）网联生态泛化测试：测试系统在功能多样性、拓展性、开放兼容及连接服务方面的表现。
3.8.2 测试指标
（1）交互准确率：系统在人机交互过程中的准确率，包括语音识别准确率、手势识别准确率和触控准确率等。
（2）响应速度：系统在接收到用户操作后的响应速度，包括界面刷新时间、指令执行时间等。
（3）交互自然度：系统在人机交互过程中的自然度，包括语音交互自然度、手势交互自然度和界面布局自然度等。
（4）个性化程度：系统在人机交互过程中的个性化程度，包括用户偏好、历史记录和推荐等。
（5）界面易用性和自适应性：系统界面的易用性和自适应性，包括界面布局、字体大小和颜色搭配等。
（6）可扩展性：系统的可扩展性，包括是否支持应用、服务及硬件扩展等。
3.9 高效性验证
3.9.1 测试方法
（1）系统评测：采用专家评测与小白用户体验结合的方式开展，可采用专业设备记录用户的操作过程，包括操作时间、视线停留时间和错误率等。
（2）问卷调查：通过问卷调查等方式，了解用户对系统的使用体验和学习成本的评价，以评估系统的易用性和易学性。
3.9.2 测试指标
（1）交互效率：测试系统在不同场景下的交互效率，包括信息传输和反馈速度、操作准确度、错误率、平均响应时间和交互成功率等。
（2）学习成本：测试系统的易用性和易学性，包括用户对系统操作的理解和学习成本等。指标包括用户学习时间、学习曲线和用户满意度等。
3.10 愉悦性验证
3.10.1 测试方法
（1）用户场景测试：通过模拟用户在不同场景下的使用情况，测试用户在使用系统过程中的情绪感受和满意度，包括测量用户的心率、皮肤电反应和呼吸频率等生理指标，评估用户在使用系统过程中的情绪感受。
（2）用户调查：通过用户调查、用户访谈等方式，了解用户对系统的使用体验和情感感受，了解用户的满意度及对系统的推荐度、使用体验和改进建议等。
3.10.2 测试指标
（1）用户情绪感受：测试用户在使用系统过程中的情绪感受，包括用户的信任感、趣味性和认同感等。指标包括用户满意度、信任度和认同感等。
（2）用户满意度：测试用户对系统的满意度，包括系统的功能、操作和界面设计等方面。指标包括用户满意度、用户体验度和用户推荐度等。
4 结束语
目前，汽车的网联化和智能化已进入快速发展和产品竞争深水区[5]，优秀的架构设计及其高效的验证体系已成为各主机厂的基础能力。本文通过建立网联系统的架构设计原则，提练关键特性，建立了覆盖系统设计、产品视角和用户体验的全面验证体系，期望能给相关机构或单位提供参考。
【参考文献】
[1]周晓翠,崔长军,钟涛等.基于Aspice 的汽车软件开发流程实践[J].汽车实用技术,2020(01):109-110+125.
[2]中国汽车工程学会.汽车智能座舱分级与综合评价白皮书[EB/OL].（2023-04-20）[2023-06-06].https://www.xdyanbao.com/doc/p0xyjhgghk?bd_vid=11535586730414578067.
[3]郑茂宽.智能产品服务生态系统理论与方法研究[D].上海:上海交通大学,2018.
[4]武翔宇,赵德华,郝铁亮.浅谈汽车OTA 的现状与未来发展趋势[J].汽车实用技术,2019(03):214-216.
[5]吕钊凤.李克强教授：中国智能网联汽车产业化的五大挑战及八条建议[J].智能网联汽车,2019(04):16-20.
END
