端云结合多模态融合人机交互在汽车上的应用研究

郑红丽 刘朝阳 吴明哲 樊永友 蔡旭

（中国第一汽车股份有限公司研发总院，长春 130013）

缩略语

V2X Vehicle To X(Everything)

AI Artificial Intelligence

CPU Central Processing Unit

GPU Graphic Processing Unit

DSI Display Serial Interface Specification

CSI Camera Serial Interface Specification

App Application

OTA Over-The-Air Technology

DMS Driver Monitor System

OMS Occupancy Monitor System

CP Content Provider

SP Service Provider

FLOPS Floating-point Operations Per Second

OPS Operations Per Second

DMIPIS Dhrystone Million Instructions executed Per Second

MACS Multiply-Accumulate Operations

0 引言

随着芯片技术、V2X 技术、云技术、传感器技术、图像识别技术和语音识别技术不断进步，越来越多的新设备、新技术应用在汽车上，使得汽车人机交互内容、交互方式也越来越丰富。传统、单一的人机交互方式已经不适用于当前汽车生态环境与用户需求，用户对驾乘体验要求也不局限于单一的驾乘体验，更加多元化、智能化和个性化需求不断增多。汽车已经不是一个单一的交通工具，而是集交通工具、移动办公设备和移动生活空间于一体的人类生活中不可缺少的生活伴侣。

随着新设备、新技术的应用，使得驾驶员要处理的信息越来越多。驾驶员在执行监控道路状况和控制车辆的驾驶任务同时，还需执行大量与驾驶有关或无关的信息交互次级任务。这些次级任务在不同程度上占用驾驶员的视觉、听觉认知资源，分散驾驶员注意力，并产生较高的认知负荷，严重影响安全驾驶和交通效能[1]。

在保证安全驾驶的前提下，如何综合利用这些信息，提高驾乘体验，减少用户、汽车企业后期的维护成本是本文制定方案的最主要目标。

1 AI与芯片

综合利用新设备、新技术产生的各种信息，满足用户不断增长的需求，可以持续提升汽车驾乘体验，其中人工智能（Artificial Intelligence，AI）在提升驾乘体验中将扮演很重要角色。

AI 即是人类依据人脑具备的智力表现，使所研制的“机器”具有人一样的智能[2-4]。在智能制造方面，AI 技术的出现取代了传统手工生产模式，而且精准、高效的表现也使得AI 技术备受社会各行业高度重视[5-7]。

基于安全和系统架构的考虑，一般不会将AI部署到车控域、自动驾驶域和信息娱乐域中。自动驾驶域中的AI是用来处理自动驾驶和驾驶辅助任务，而本文所述的信息和需求是用户直接感官感受的信息，对软硬件安全需求较低，因此将这部分AI部署到信息娱乐域中是安全的[8-14]。

于继成等[15]对目前主流AI芯片算力进行了总结，并提出采用算力初始冗余量，对AI 芯片算力进行评估，AI芯片算力统计数据如表1所示。

表1 芯片厂家部分AI芯片算力表

对于车规级信息娱乐域控制芯片，除了考虑中央处理器（Central Processing Unit, CPU）和图形处理器（Graphic Processing Unit,GPU）算力，还需要考虑连接屏幕和摄像头数量。根据NXP、瑞萨、高通等芯片厂商数据[16-24]，总结芯片参数见表2。

表2 车规级信息娱乐域控制芯片参数

虽然终端芯片发展很迅速，计算能力也不断大幅度提升。但是座舱多方面对芯片需求也不断增加，综合成本方面考虑，即使车端芯片性能有所提高，可提供给AI的算力也是有限的。

为解决车端芯片AI算力不足问题，研究人员提出云计算可以作为重要的技术解决方案之一。Whaiduzzaman等[25]提出通过云计算技术，汽车只需通过无线连接到远程一台或多台计算机进行AI运算，这将极大降低车端AI运算成本，并能提高AI运算效率。

2 云计算与5G网络

2.1 云计算优势

在智能座舱中应用云计算优势[26]（图1）如下。

图1 云计算优势[26]

（1）云计算优势在于高灵活性、可扩展性和高性价比。云计算能力远大于车端芯片运算能力，云计算不会占用车端运算时间，也不会占用车内零部件空间，同时可减少了车端芯片升级带来的成本增加。

（2）利用云计算进行大范围、大批量的样本采集和训练。每个车端都可以成为云端的样本采集器，这样可以使样本采集更多样化、个性化。使用采集的样本和获得的海量大数据，可以对AI模型进行更多、更精准的训练。

（3）云计算可充分利用云服务优势，灵活按需发布计算模型或升级包，这样可极大减少车端升级需求，并能提供更好的升级体验。

2.2 云计算不足

在智能座舱中应用云计算的不足是运算实时性差，而移动网络通信速度和稳定性是制约云计算实时性的主要因素[27]。

近年来，随着5G通讯技术大规模落地实施，理论上通信速度已不再是制约因素[28]。但是受到基础设施建设和地理的限制，5G信号无法达到全地形和全天候覆盖[29]。

3 端云结合多模态融合人机交互方案

运用云端计算优势，减少云端计算不足带来的影响，并且将人工智能应用到车内场景中，成为目前汽车行业需要解决的热点问题。本文采用了端云结合方案作为多模态融合的人机交互方案基础。

3.1 方案概述

（1）云端AI模型是基础模型，AI模型根据车端输入的信息结合云端各种信息不断学习，并形成执行动作，然后将车端输入的信息结合云端各种信息生成判断条件，将形成的执行动作生成交互内容，并将判断条件和交互内容进行序列化，生成规则化的交互脚本（简称“脚本”）。这样云端就可以将交互脚本不断生成系列交互场景，最终形成一个庞大场景库，通过车载网络，将脚本传输到车端。

（2）在车端部署系列应用，提供交互能力列表和交互接口。

（3）在车端部署规则引擎，规则引擎可以识别脚本中的判断条件。

（4）在车端部署执行引擎，将脚本内的交互内容发送给系列应用，实现多种交互。

3.2 端云系统架构

根据端云结合多模态融合人机交互方案，生成如图2所示的端云系统架构。

图2 端云系统架构

3.2.1 云端

云端部署2大模块，具体阐述如下。

（1）云端融合分析决策引擎（基于AI）

（a）接收车联网和车端推送过来的事件和实时信息，记录实时信息。

（b）在场景库中将新识别出来的场景进行更新。

（c）通过AI 算法对当前场景和策略库、实时信息和新输入事件进行推理，依据推理结果更新策略库。

（2）场景策略引擎

包含场景、策略定义和存储2大基本功能，即场景策略引擎和场景策略库。

产品场景定义开发工程师可通过场景策略引擎，定义场景和场景处理策略。

通过AI 融合分析决策引擎将识别的场景和处理策略存储到场景策略库。

通过AI识别场景，融合分析决策引擎将用户操作在场景策略库中进行记录，作为个性化交互内容进行 存储。

3.2.2 车端

车端部署4大模块，具体阐述如下。

（1）多模式输入预处理模块

对接收的输入进行预处理，推送给融合分析决策引擎和云端。

（2）场景策略库模块

从云端同步场景和策略信息。

（3）实时信息模块

记录当时车况实时信息。

（4）融合分析决策引擎模块

接收新输入事件，记录实时信息。

场景识别，并依据场景、策略库和实时信息做出决策。

3.2.3 信息同步引擎

信息同步主要分为以下2部分：

（1）云端服务信息检索引擎

云数据筛选和获取及V2X信息获取。

（2）云端和车端信息同步引擎

在车端和云端分别部署客户端及服务端。

车端负责获取汽车上各种输入信息，包括传感器、摄像头及语音信息。

云端负责接收数据，并将收集到的多种云端信息和V2X信息传输给车端。

3.3 运行流程

车端在运行时，会将车端信息通过车载网络不断与云端进行同步，而车端也会收到云端不断同步到车端的信息。

当云端识别出某一场景时，则将脚本发送到车端的执行引擎中进行执行，以到云端交互的目的。

当车端的规则引擎根据判断条件判断出当前的状态满足某一场景时，车端也可将脚本发送给执行引擎进行执行，以达到车端交互的目的。

执行引擎和规则引擎也有各自的规则，例如：

（1）规则引擎在网络不畅或断开时，可以触发场景的规则。

（2）执行引擎同时收到云端脚本和车端脚本，如何处理的规则。

这些规则内容不在本文阐述范围内，是另一项重要研究内容。

3.4 方案优势与不足

与传统方案中通过信息娱乐系统内的App 实现各种交互场景相比，端云结合方案有很多优势，详见表3。

表3 端云结合方案与传统方案对比

而与车端AI实现的交互场景相比，本方案具备的优势见表4。

表4 端云结合方案与车端AI方案对比

基于以上优势，端云结合方案可为用户减少线下升级时间，为用户提供更快的优质服务。端云结合方案更符合现代车辆主机厂（Original Equipment Manufacture，OEM）转型需求，可快速、便捷地为用户释放体验优质的服务，满足新的运营模式需求。

端云结合方案也存在不足之处，由于场景库不断壮大，脚本也将不断增多，车端规则引擎性能会有所下降，并且对脚本存储的要求也不断增加。

3.5 多模态融合人机交互场景应用分析

多模态融合人机交互场景数量非常庞大，以目前车内传感器、车外传感器和云数据分析，其场景数据量为百万级，本文仅针对吸烟和电话这2个场景进行应用分析。

3.5.1 吸烟模式

在多模态融合人机交互吸烟模式需要采集的总体信息包括：

（1）系统需要感知每个位置用户的吸烟信息，并将结果上报给多模融合分析引擎。

（2）多模感知输入的信息源：

每个座位摄像头视觉输入：监测用户是否有吸烟行为。

每个座位用户画像输入：用户性别、年龄、是否为特殊乘客（老人、小孩、孕妇）。

（3）整车全部车窗开启情况：车内空调设备和香薰设备的开启及设定状态。

（4）车内空气情况监测。

（5）车外天气情况监测和车外空气质量监测。

（6）车辆行驶速度及定位位置（是否高速行驶，是在高速公路或是普通路上行驶）。

多模态融合人机交互吸烟模式包括4 种特殊场景：（1）有特殊乘客，（2）高速行驶安全提醒，（3）一般天气，（4）异常天气。

（1）吸烟模式：有特殊乘客

（a）多模输入：

·驾驶员监控系统（Driver Monitor System，DMS）判断驾驶员吸烟动作。

·乘员监控系统（Occupancy Monitor System，OMS）识别乘客身份（特殊乘客：老人、小孩、孕妇）及乘客吸烟动作。

（b）多模交互：

·监测到有特殊乘客时，建议吸烟人（准备吸烟或正在吸烟）停止吸烟，AI 助手显示：“您的车内有老人（小孩、孕妇），为了他们的健康考虑，建议您暂时不要吸烟呢”（静音，文字显示提醒一次）。

（2）吸烟模式：高速行驶安全提醒

（a）多模输入：

·车辆行驶速度（≥60 km/h；≥80 km/h）。

·DMS判断驾驶员吸烟动作。

（b）多模交互：

·监测到车辆行驶速度≥60 km/h 时，若吸烟人为驾驶员，建议专心驾驶（AI助手提示：“当前车速较快，建议主人您专心驾驶”）。

·监测到车辆行驶速度≥80 km/h，若吸烟人为驾驶员，告警提示需要专心驾驶，吸烟为分心的危险行为（AI 助手提示：“当前车速很高，吸烟是很分心的行为，非常危险，您必须专心驾驶）。

注：该模式为驾驶员的行驶安全提醒，其他乘员吸烟暂未涉及驾驶安全，故暂未定义其他乘员吸烟时需要执行的操作。

（3）吸烟模式：一般天气

（a）多模输入：

·网络实时天气数据。

·车外空气质量（PM2.5）。

·DMS判断驾驶员吸烟动作。

·OMS判断乘客吸烟动作。

（b）多模交互：

·监测到有用户吸烟时，若无异常天气（包括中雨及以上、3级风及以上、沙尘暴、中度污染及以上）。

·语音提示用户：已为您适度打开车窗，建议您使用烟灰缸（屏幕提示烟火缸位置，若可自动弹出，则自动弹出）。

·车速大于60 km/h，不执行一般天气的吸烟模式。

（c）多模输出：

·打开吸烟用户最邻近的车窗（不含天窗），车窗玻璃下降幅度默认为3 cm，视车外天气优劣情况，打开幅度可以自动增加或减少2 cm。

（4）吸烟模式：异常天气

（a）多模输入：

·网络实时天气数据。

·车外空气质量（PM2.5）。

·DMS判断驾驶员吸烟动作。

·OMS判断乘客吸烟动作。

（b）多模交互：

·监测到有用户吸烟时，若有异常天气（包括中雨及以上、3级风及以上、沙尘暴、中度污染及以上）。

·语音提示用户：车外天气（空气）较差，已为您打开空调新风、空气过滤及香薰，但车辆换气净化能力有限，建议您减少吸烟并使用烟灰缸。

·车速大于60 km/h，不执行异常天气的吸烟模式。

（c）多模输出：

打开空调新风加上空气过滤，打开香薰，若有烟灰缸，自动弹出或提示位置。

3.5.2 多模电话场景

针对多模交互电话场景，需要针对车内驾乘人员使用电话情况，进行多模调整音频、车窗和天窗，以便于电话使用者能有安静的环境进行通话，同时又兼顾车内其他乘客体验。

（1）车内仅驾驶员

驾驶员使用手机电话时，采用多模调整音频。

功能详细描述：

（a）前提：车内音、视频在播放，包括在线或本地音乐、广播、在线电台、视频。

（b）车内仅驾驶员，检测到使用电话时（包括听筒接听或免提，下同），降低全车音量到2级；驾驶员使用完电话后，恢复到原来音量状态。

（c）调整时，仪表提示降低全车音量，并提示开车过程中使用蓝牙电话。文案：“已调低音量，开车中请使用蓝牙电话”。5 s后，提示消失（下同）。

（d）恢复时，仪表提示音量恢复。文案：“音量已恢复”。

反馈：

如果用户在音量调整后再进行音量调节，可能往高调也可能往低调。下次进行多模音量调整时，按用户设定的音量进行调整。

（2）车内坐2人

驾驶员使用手机电话时，采用多模调整音频。

功能详细描述：

（a）车内有2 人，检测到驾驶员使用电话时，将音场调到另一个人所在的位置（副驾驶员位置或后排），驾驶员使用完电话后，恢复音场原来状态。

（b）调整时，仪表提示音场调节，并提示开车过程中使用蓝牙电话。文案：“已调整音场，避免干扰通话，开车中请使用蓝牙电话”。

（c）恢复时，仪表提示音量恢复。文案：“音场已恢复”。

（3）车内坐2人

副驾驶员或后排乘员用电话时的多模调整音频。

功能详细描述：

（a）车内有2人，检测到副驾驶员或后排乘员使用电话时，将音场调到主驾位置。副驾驶员或后排乘员使用完电话后，恢复音场原来状态。

（b）调整时，仪表提示音场调节，文案：“已调整音场，避免干扰通话”。

（c）恢复时，仪表提示音量恢复。文案：“音场已恢复”。

（4）车内坐满乘员

车内有乘员使用电话时的多模调整音频。

功能详细描述：

（a）车内乘坐全部乘员时，当检测到车内（驾驶员或副驾驶员或后排乘员之一）使用电话，降低全车音量到2级。车内使用完电话后，恢复到原来音量状态。

（b）调整时，仪表提示降低全车音量，文案：“调低音量，避免干扰通话”。

（c）恢复时，仪表提示音量恢复。文案：“音量已恢复”。

反馈：

如果用户在音量调整后进行音量调节，可能往高调也可能往低调。下次进行多模音量调整时，按用户设定的音量进行调整。

（5）音场与使用电话位置

当音场不在当前使用电话位置时，不对音频进行多模调整。

功能详细描述:

如果音场不在当前使用电话位置，则不对音频进主处理。

（6）使用耳机

当使用耳机时，音频不受电话多模影响。

功能详细描述：

如果某一座位乘员在使用耳机，则相当于该座位没有乘员，不对该座位的音频策略进行调整，其它逻辑和前同。

（7）其它音源

其它音源不做多模调整音频处理。

功能详细描述：

当语音（语音助手发声）、导航音、报警音等其它音源播放时，和使用电话不进行关联处理，因此不进行调整音频。

（8）驾驶员使用蓝牙电话

当驾驶员使用蓝牙电话时，进行多模调整车窗。功能详细描述：

（a）前提：驾驶员旁车窗处于打开状态。

（b）检测到驾驶员使用蓝牙电话时，关闭驾驶员旁车窗，电话结束时恢复原来状态。

（c）关车窗时，仪表提示关闭车窗，文案：“已关闭车窗，避免干扰通话”。

（d）开车窗时，仪表提示恢复车窗位置，文案“车窗位置已恢复”。

反馈：

如果用户在关闭车窗后手动进行车窗操作，下次进行多模车窗调整时，按用户最后调整的车窗位置进行调整。

（9）驾驶员使用蓝牙电话

当驾驶员使用蓝牙电话时，进行多模调整天窗。功能详细描述：

（a）前提：天窗处于打开状态。

（b）检测到驾驶员使用电话时，自动关闭天窗，电话放下时恢复天窗原来状态。

（c）关闭天窗时，仪表提示关闭天窗，并提示开车过程中使用电话不安全。文案：“已关闭天窗，避免干扰通话，开车中请使用蓝牙电话”。

（d）开天窗时，仪表提示恢复天窗位置，文案：“天窗位置已恢复”。

反馈：

如果用户在关闭天窗后手动进行天窗操作，下次进行多模天窗调整时，按用户最后调整的天窗位置进行调整。

（10）车内驾乘人员使用手机电话时车窗调整

当车内驾乘人员使用手机电话时，进行多模调整车窗。

功能详细描述：

（a）前提：副驾驶员位置车窗和后排车窗处于开着状态。

（b）检测到副驾驶员或后排乘员使用电话时，关闭对应副驾驶员位置车窗或后排车窗，电话放下时恢复车窗原来状态。

（c）关车窗时，仪表提示关闭车窗，文案：“已关闭副驾驶员位置或后排车窗，避免干扰通话”。

（d）开车窗时，仪表提示恢复车窗位置，文案：“车窗位置已恢复”。

反馈：

如果用户在关闭车窗后手动进行车窗操作，下次进行多模车窗调整时，按用户最后调整的车窗位置进行调整。

（11）车内驾乘人员使用手机电话时天窗调整

当车内驾乘人员使用手机电话时，进行多模调整天窗。

功能详细描述：

（a）前提：天窗处于打开状态。

（b）检测到副驾驶员或后排乘员使用电话时，自动关闭天窗，电话放下时恢复天窗原来状态。

（c）关闭天窗时，仪表提示关闭天窗，文案：“已关闭天窗，避免干扰通话”。

（d）开闭天窗时，仪表提示恢复车窗位置，文案：“天窗位置已恢复”。

反馈：

如果用户在关闭天窗后手动进行天窗操作，下次进行多模天窗调整时，按用户设定的天窗位置进行调整。

4 结束语

本文阐述了端云结合的多模态融合人机交互方案，即可充分利用云端计算的各种优势，也可弥补云端和车端算力不足的缺陷，同时也兼顾了在网络不稳定时，车端独立运算的运行模式。

基础网络建设在短时间不能达到理想状态，那么在未来很长一段时间内，本文提出的多模态融合人机交互方案可以很好地解决网络状态不理想时，云端处理不及时需要车端进行独立处理的问题。

未来，端云结合的人机交互还需要更深入的探索和研究，例如：云端数据可以打通更多的V2X通路，如智慧城市数据、智能交通数据和车与车间数据等。车端数据也可更多地共享到云端，如车端的摄像头数据、自动驾驶识别的道路数据等。随着数据的不断积累，端云结合的人机交互场景将越来越丰富。