前沿
在上一期《基于SusPIS-ATx的座舱仿真系统搭建与评估方法创意研讨会》中，我们围绕汽车智能座舱仿真测试相关评价规范和法规（如C-ICAP），引入了智能座舱测试行业难点及次生问题，介绍了基于SusPIS-ATx的智能座舱全域功能及性能仿真测试技术路线、系统搭建和评估方法。然而难免会有一些问题仍困靠我们，今天小编就为大家带来关于智能座舱SusPIS-ATx系统的相关问题解析及对应的解决方案。
正文
Q1：
智能座舱SusPIS-ATx系统具体指的是什么？
A1：
SusPIS-ATx是智能座舱感知与交互系统自动化测试验证平台（SusPIS-ATP）和智能座舱感知与交互系统自动化测试软件（SusPIS-ATS）的统称。其中SusPIS-ATP，指硬件方案平台；SusPIS-ATS指自动化测试软件平台，提供脚本编辑执行、用例导入导出、测试报告导出生成、ADB测试、总线分析与仿真、外设交互、视觉分析（含图像断言）、语音测试、机械触控仿真、HIL信号仿真等功能。
Q2：
智能座舱仿真测试都有哪些相关的评价规范和参考标准？
A2：
智能座舱仿真测试相关的评价规范及参考标准包括但不限于以下内容：
| 序号 | 标准/规范 | 类型 |
| 1 | 《信息技术 智能语音交互系统 第1部分：通用规范》 | 国标 |
| 2 | 《信息技术 智能语音交互系统 第5部分：车载终端》 | 国标 |
| 3 | 《信息安全技术 蓝牙安全指南》 | 国标 |
| 4 | 《信息技术 智能语音交互测试方法 第1部分：语音识别》 | 国标 |
| 5 | 《信息技术 智能语音交互测试方法 第2部分：语义理解》 | 国标 |
| 6 | 《移动终端人系统交互工效学 触控界面感知流畅性》 | 国标 |
| 7 | 《汽车软件升级通用技术要求》 | 国标 |
| 8 | 《中国智能网联汽车技术规程（C-ICAP）》 | 行业标准 |
| 9 | 《智能终端显示流畅性测试用机器人技术规范》 | 团体标准 |
Q3：
SusPIS-ATx系统中机械臂控制接口、语音交互接口等是自研方案吗？
A3：
SusPIS-ATx系统中机械臂控制接口采用自研方案，语音交互通过集成市面主流语音引擎，如科大讯飞、Nuance等，结合仿真嘴、拾音器等专业设备以实现TTS/STT语音转换等功能。
语音交互测试方案原理图
Q4：
仪表中控自动化测试的测试过程是通过摄像头来监测吗？
A4：
对于常规的功能测试，一般采用ADB截图+总线信息监控的方式，也可根据需求配备高清相机。若有性能测试的需求，则需要追加一些性能测试的组件设备，比如使用高帧相机进行高速图像抓取，结合上位机SusPIS-ATS软件算法对图像进行逐帧提取标识元素，进而计算帧间差，完成响应时间、完成时延等性能测试项。
Q5：
智能座舱AR-HUD如何进行测试？会与总线信号一起进行测试吗？
A5：
对于台架测试，可搭建一个AR-HUD专用测试台架，台架安装有可调节的前挡风玻璃、定位夹具（用于安装AR-HUD实车件），通过六轴机械臂上安装的工业相机采集挡风玻璃上的成像。
对于实车测试，可通过工业相机采集仪表、中控、以及前挡风玻璃的AR-HUD成像，通过上位机软件算法进行图像对比，以进行信息显示同步性等测试项。
AR-HUD测试过程中会监控总线信号，因为AR-HUD使用场景需要与其他车载系统如导航、传感器等进行协调工作，监控总线信号可以确保各系统之间数据交换与通信的准确性。
Q6：
抬头显示防眩目之类的相关测试，需要搭建怎样的测试环境？
A6：
防眩目功能测试是为了确保在各种光照条件下，驾驶员均可清晰看到显示信息，而不受外部光线干扰。测试环境应配备全光谱光谱仪，用于测试HUD显示区域的光谱分布及亮度。还应配备高精度点光源设备，通过照射后视镜来模拟来自后方车辆的灯光，通过光度计测量反射光的强度是否在预期内。
Q7：
为提高性能测试有效性，是需要在各种极端环境下进行monkey等稳定性测试吗？
A7：
为提高性能测试有效性，确实需要在极端环境（如高温、低温、电压冲击等环境）下进行稳定性测试，Monkey是压力测试其中的一部分，此外还包含机械臂仿真的长时间的高频点击测试、多个软件并行的高负荷测试、模拟用户场景测试、外界干扰测试等。
Q8：
在性能测试的结果中，卡死、黑屏等问题出现的数量是多少？
A8：
性能测试结果中卡死、黑屏等问题出现的数量取决于多种因素，包含待测件本身硬件性能、软件系统稳定性等影响，难以给出确切的数字。然而，根据过往项目经验，可提供一个大致的参考范围，即：每1000个用例中会检出8~10个bug。通过持续的测试和改进，可逐渐降低bug出现概率，确保最终产品的性能及稳定性满足客户期望。
Q9：
被测件在测试执行过程中触发意外弹窗（如电量过低、网络异常等），是否会影响自动化测试过程？
A9：
SusPIS-ATx系统充分考虑了此类问题，在用例开发阶段提前将意外弹窗进行分类，并保存目标图像在测试系统内进行标定即可。在实际测试执行中，设备界面会首先与目标图像进行模板匹配，再与标定的意外弹窗对比，若对比成功则判定为出现意外弹窗，可通过ADB或机械臂方式关闭意外弹窗，并继续执行用例，测试报告中会呈现意外弹窗出现的时刻、及过程图像等信息。若意外弹窗对比失败，则判定为被测件出现异常情况，如黑屏、卡屏、死机等，出现的时刻及过程信息会形成在报告中，便于后续问题定位。
