端云結合多模態融合人機交互在汽車上的應用研究

鄭紅麗 劉朝陽 吳明哲 樊永友 蔡旭

（中國第一汽車股份有限公司研發總院，長春 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通路，如智慧城市數據、智能交通數據和車與車間數據等。車端數據也可更多地共享到云端，如車端的攝像頭數據、自動駕駛識別的道路數據等。隨著數據的不斷積累，端云結合的人機交互場景將越來越豐富。