彭方強 ， 錢 威 ， 王泰安 ， 彭昌波 ， 邱聰雨

（1.極氪汽車 （寧波杭州灣新區(qū)）有限公司， 浙江 寧波 315336；2.吉利汽車研究院 （寧波）有限公司， 浙江 寧波 315336）

1 前言

隨著汽車智能化、網聯化不斷演進，各種功能增加，智能互聯汽車各個系統(tǒng)的集成度越來越高，系統(tǒng)之間的關聯關系變得愈加復雜。一方面，系統(tǒng)內部集成功能越來越多，耦合程度越來越緊密；另一方面，智能互聯汽車市場需求個性化越來越高，為了更好地占領市場，汽車公司進行多品種、多車型的汽車開發(fā)和生產。為了解決新車開發(fā)時間長成本高與快速且成本低開發(fā)的矛盾，汽車平臺化設計應運而生。

平臺，從概念上講，是指基礎，一般主要指具有通用性的技術基礎、結構基礎或業(yè)務基礎［1］，本文平臺指的是通用性的技術基礎。

智能互聯汽車功能需求在不斷迭代增加，智能體驗也在不斷提高。作為主打智能科技的各種屏幕也越來越多，數字儀表、抬頭顯示器、中控屏、后排座椅屏、扶手屏等，各個屏內彈出的文本消息提醒或是帶有圖文的消息也越來越多，人機交互作為駕乘人員與車輛溝通的重要紐帶，各個功能的操作提醒、故障提示都需要呈現給用戶。智能互聯汽車功能多達幾百項，不僅包含常規(guī)的驅動控制，能源管理，主、被動安全，還包括智能座艙和自動駕駛。從功能域的角度來看，對用戶的操作使用影響、關注的程度也并非在一個等級上，即使是在同一功能下，不同內容的顯示也需要根據服務場景、用意進行區(qū)分判斷，不能一概而論，因此需要對彈窗信息進行分類規(guī)劃，定義優(yōu)先級、顯示時長、指示燈和提示音等都需要彈窗信息數據庫開發(fā)。

智能互聯汽車彈窗信息數據庫平臺開發(fā)主要是為了適應不同項目需求，縮短車輛的設計開發(fā)周期，降低產品設計成本，采用平臺化設計以提高通用化的理念，以更低的開發(fā)成本和更短的開發(fā)周期來實現更多智能互聯車型產品開發(fā)和生產。

2 平臺要求

平臺的基礎是通用化和標準化，通用化是建立在標準化的基礎上，彈窗數據庫的開發(fā)模板要求標準化，在開發(fā)初期就要求統(tǒng)一，平臺按照此模板收集各項目的功能需求，相同功能需求放在一塊，便于開發(fā)過程中的合并和優(yōu)化。

2.1 平臺開發(fā)范圍

1）平臺開發(fā)范圍需要明確定義哪些屏幕彈窗屬于平臺開發(fā)，哪些屏幕彈窗屬于項目獨有開發(fā)。如圖1所示。彈窗數據庫標準化應明確：功能名稱、彈窗ID、文字ID、符號ID、功能優(yōu)先級、屏幕的超時顯示時間和最小顯示時間、提醒/報警音源。如表1所示，功能名稱和彈窗ID由平臺統(tǒng)一定義，彈窗ID必須是唯一的，因為要和系統(tǒng)觸發(fā)邏輯進行匹配；在平臺許可下，可以給項目分配獨有字段ID，其余項參數則可支持項目按照自己造型風格更改 （注意：表1中的參數僅示例）。平臺開發(fā)范圍包括但不僅限于以下項目：工具、流程、交付物；彈窗數據庫；文本數據庫；符號數據庫；音源數據庫；系統(tǒng)軟件平臺消息處理程序；多媒體協(xié)議。

圖1 領克05HUD領航輔助彈窗［2］

表1 彈窗信息數據庫

2）車型項目開發(fā)范圍為：UI，UE，動畫，微動效；字體；音源文件。

3）平臺職責：承接功能需求，確保方案平臺化；開發(fā)平臺數據庫，開發(fā)系統(tǒng)邏輯。

4）項目職責：確保系統(tǒng)邏輯與UE一致；確保平臺數據庫在項目正確使用；參數標定，測試問題分析。

2.2 平臺策略定義

1）平臺策略

平臺策略要求方案平臺化，同一個功能，各車型項目實現的方案應確保一致，這樣系統(tǒng)觸發(fā)條件一致，平臺的彈窗信息數據庫應收集所有項目的功能需求，是一個合集，按照統(tǒng)一的策略進行開發(fā)，平臺數據庫可迭代，增量化開發(fā)，可以創(chuàng)建新的彈窗信息來滿足新增車型的需求。

平臺數據庫最大化開發(fā)分為大版本發(fā)布、小版本更新，按照時間點平行化開發(fā)，如圖2所示，車型數據庫則是每個節(jié)點直接從平臺數據庫進行分支開發(fā)，大版本同步一次，小版本根據項目需求迭代一次或多次。

圖2 車型分支策略

2）版本規(guī)則

版本管理是為了對軟件開發(fā)過程中所創(chuàng)建的配置對象的不同版本進行管理，保證任何時間都可以取得正確的版本以及版本的組合，版本規(guī)則需要體現以下要素：平臺大版本，小版本，開發(fā)階段；項目大版本，小版本，開發(fā)階段；可管理，可追溯。

2.3 開放性和靈活性

1）通過Notification ID索引。智能互聯汽車由于功能多，所以彈窗信息數量也多，多達幾百條。為了便于查找、管理、修改，可以通過notification ID進行索引，平臺化和不同車型分配不同字段的ID，平臺化通用部分定義ID1～300，再依次是車型A項目ID字段，ID301～400，車型B項目字段，ID401～500，依此類推。這樣做的優(yōu)點是通過Notification ID就知道是平臺化需求還是項目需求，也可更好地和系統(tǒng)觸發(fā)邏輯進行匹配。

2）支持各車型關聯參數標定更改。每個車型屏幕上的報警符號、報警音、文本表達都有其車型特色，彈窗信息數據庫應滿足不同車型需要，支持車型關聯參數標定更改。如顯示時間、用戶模式，這些參數也可以支持標定更改。

3）支持軟件不同變種。同一個車型有低、中、高配，不同車型之間差異更多，所以彈窗信息數據庫應支持軟件的不同變種。

4）支持車輛配置。每個車型在某個配置族只能選擇一個配置進行定義，不同車型在同一個配置族可能會有不同的配置值。配置的存在，降低了系統(tǒng)的復雜度，減少了軟件的版本數量，維持了平臺化的系統(tǒng)開發(fā)。

2.4 擴展性

支持平臺功能擴展，通過增加Notification ID添加新的功能；車型量產后，也可以通過OTA添加新的彈窗信息。

3 平臺構建

彈窗信息數據庫平臺主要由UI/UE、報警音和提示音以及操作系統(tǒng)、系統(tǒng)硬件、軟件等部分構成［3］。構建開放式彈窗信息人機交互平臺需要綜合考慮以下部分內容。由于操作系統(tǒng)和系統(tǒng)硬件非本文討論范圍，這里不做分析。

3.1 UI/UE

UI/UE包含文本數據庫和符號數據庫，文本應該規(guī)范用語，力求簡潔實用，如：“請執(zhí)行定期保養(yǎng)、ACC自適應巡航不可用、駕駛員未系安全帶”等，文本數據庫包括文本用詞及其翻譯，文本框需要定義行數、每行字符數、字符總數、每行漢字個數、像素長/高值等；符號數據庫包含符號ID，ID1～200定義為平臺通用部分，相同功能的應具有相同的ID，在平臺符號庫中進行定義，ID200以后的應用于項目，項目可以設計項目特定的符號、顏色、大小、形狀，符號對于文本消息是可選的。

3.2 報警音和提示音

由信號觸發(fā)的聲音請求，支持多種不同類型的聲音，每個車型項目音源相同也可以不同，支持獨立標定，報警音和提示音含音源文件開發(fā)，觸發(fā)策略需要與文本消息同步。

3.3 系統(tǒng)軟件平臺

系統(tǒng)的彈窗信息是由信號觸發(fā)的，所以在系統(tǒng)軟件平臺里，需要定義每條彈窗ID激活及失效的觸發(fā)條件、觸發(fā)信號、優(yōu)先級策略、邏輯以及是否有儀表指示燈，指示燈的顏色，并描述該彈窗消息用途場景，平臺信號數據庫和軟件需求規(guī)范最大化開發(fā)，支持項目標定參數差異化。

本節(jié)提出彈窗信息數據庫平臺觸發(fā)模型，如圖3所示，彈窗信息數據庫平臺總體上包括彈窗信息數據庫、庫文件、顯示界面、彈窗消息處理程序和用戶查看歷史消息等；其中庫文件又包含文字庫、符號庫、音源庫。

圖3 彈窗信息數據庫平臺觸發(fā)模型

系統(tǒng)軟件平臺實現過程為：彈窗信息處理程序負責判斷觸發(fā)條件，一旦激活條件滿足，彈窗信息被觸發(fā)，系統(tǒng)調取彈窗數據庫里的彈窗IDx，其包含文字ID、符號ID、音源ID。庫文件則根據ID號，在庫里調取相應的文字、符號、音源ID，并傳給顯示界面顯示。如有多條信息，則通過優(yōu)先級策略仲裁進行排序，當消息位于隊列頂部時，則通過顯示界面顯示給用戶，直到超時或被用戶確認，或不再被觸發(fā)，彈窗消息消失，此時系統(tǒng)會按照顯示時間進行隊列存儲，用戶可通過菜單或其余方式調出歷史彈窗信息，方便用戶查看。

顯示在不同屏幕上的操作提醒、警告和故障信息是由各種車端ECU發(fā)送的數據［4］，在顯示前，系統(tǒng)會根據定義策略對所有的ECU信息進行分類評估，對于同一個屏、同一顯示區(qū)域的消息，按照定義好的優(yōu)先級顯示，駕駛相關的信息需要定義在抬頭顯示器和數字儀表上，以數字儀表和抬頭顯示器為例，根據影響大小來區(qū)分：①嚴重影響行車安全的；②是否有功能安全等級；③智能駕駛退出需要人為立即接管；④一般服務提示或故障；⑤用戶提醒。

優(yōu)先級高的可以打斷優(yōu)先級低的，優(yōu)先級1可以打斷優(yōu)先級2，3，4，優(yōu)先級2可以打斷3，4；同等優(yōu)先級之間，正在顯示的消息顯示最小定義時間后才能被新來的報警消息打斷，一個駕駛循壞內，除優(yōu)先級1外其余允許用戶主動關閉。

同一個屏幕上也有幾個顯示區(qū)域，如中控大屏上標題欄有消息中心，可以記錄系統(tǒng)軟件評估歷史故障信息，在其中間區(qū)域上，可以做場景驅動的消息提醒，基于用戶習慣和環(huán)境改變，系統(tǒng)自動預測下一個任務，提示用戶操作的圖形化信息提醒，還有底部消息欄，主要是一些短時提示信息，如藍牙已連接等。

3.4 配置管理

總體來說，同平臺車型項目有很多通用的功能需求，也有差異化的功能，如圖4所示，顯示屏上的UI/UE設計相似性大，顯示屏尺寸參數類似，各種開關的操作邏輯相同，系統(tǒng)軟件平臺設計采用平臺化設計，通過配置區(qū)分不同的項目的差異化。

圖4 平臺與車型項目的關系

3.5 問題修正

在彈窗數據庫發(fā)布后，如測試或售后發(fā)現一些問題需要快速修改，并需要重新發(fā)布，此時如車型的彈窗信息數據庫的發(fā)布計劃不足以滿足要求，這時需要問題修正，并升級車型數據庫版本，需要融合到平臺數據庫的，平臺數據庫也需要修正并升級版本維護。

4 場景驅動的智能彈窗主動服務

智能互聯汽車具備完整的信息架構，具備強大精準的智能化算法驅動的引擎可以將彈窗信息與手勢、語音融合［5］，當觸發(fā)到場景引擎時，主動彈窗信息服務被喚醒，可以在恰當的時機把信息和服務主動呈現給用戶，比如車內PM2.5值過高，語音播報的同時，自動彈窗提醒用戶是否打開空氣凈化裝置，以提高車內空氣品質，這時用戶可以用手點擊或是語音，手勢確認打開，系統(tǒng)就可以主動工作。

5 總結

本文介紹的智能互聯汽車彈窗信息數據平臺開發(fā)的設計方法，是立足于現在國內、國外智能互聯汽車的發(fā)展趨勢及汽車行業(yè)智能化、網聯化大背景下提出的［6］，為了解決不同車型差異性和通用性矛盾。一種新的可縮短開發(fā)周期、降低開發(fā)成本的彈窗信息數據庫平臺開發(fā)方案，可以在平臺上不同車型實現最大化共享和復用，還可以通過OTA技術不斷升級迭代，更換顯示符號、顯示文字、提示音、動畫，更換時髦用語，滿足不同車型項目需求，為企業(yè)賦能。