辜 云,劉 欽,張小波,陳江波,張 懿,謝小春
(江鈴汽車股份有限公司,江西 南昌 330001)
隨著高級駕駛輔助系統ADAS、車載信息娛樂系統IVI的量產裝配,大量數據的傳輸對汽車總線傳輸帶寬和速度提出了更高的要求[1]。無人駕駛技術和新汽車座艙技術的發展,使得汽車芯片算力從多個分布式向中央集成式發展[2]。空中下載(Over The Air,OTA)技術的發展,使車云一體架構及軟件空中升級逐漸成為可能。隨著“軟件定義汽車”成為業界共識,面向服務的架構(SOA)設計思想也逐步替代面向信號的設計思想,成為汽車新一代電子電氣架構設計思想的主流[3]。
隨著電動化、智能化、網聯化、共享化已經成為汽車產業公認的未來發展方向,高計算性能、高通信帶寬、高功能安全性、高信息安全性、軟件持續更新等新的技術需求出現對整車電子電氣架構開發提出了更高的要求。面向服務架構的車云一體化搭載了智能場景引擎,可以構建多種場景,提供個性化、情感化、場景化的用戶需求。基于場景,用戶可以滿足私人定制及情感化的需求,對車的互動形成用戶黏性。智能場景引擎關聯了眾多汽車功能,利用車上布置的傳感器和執行器,形成對應的服務庫與場景庫,最后通過場景引擎賦能給最終用戶使用。智能場景引擎在云端部署了有場景引擎的能力中臺,在車端和手機端分別集成場景引擎SDK(Software Development Kit),能夠把車端能力從服務的角度管理起來,這也是整車的SOA化結合起來的點。所有服務的能力、云端的能力都可以同步,同時在云端建立可視化的管理平臺,對所有集成場景引擎SDK的車型進行管理,包括每個車型的能力庫、每個車型相關的場景庫以及當前各場景使用的情況。智能場景引擎也支持大數據分析,做主動場景推送,把個人相關的智能家居、IoT(Internet of Things)設備信息關聯進來,包括車上的數據埋點、使用APP的數據,通過數據對用戶做畫像,精準識別到用戶喜好。用戶手機端可以同步對應場景,并根據喜好和習慣自行編制專屬場景,通過車云一體化將個性化的場景直接下放到車端執行,實現可見即可用、即編即用的過程。智能場景引擎構建智能場景,給用戶帶來車能懂人的體驗,形成很好的人車互動。
SOA服務化設計首先需要研究功能架構開發流程,考慮在以往功能開發流程的基礎上做哪些更新內容,將用戶需求轉化為合理的功能實現方案,并融入服務分層理念,映射到子系統的邏輯層、軟件架構層,并部署到域控及ECU硬件中去。SOA功能開發流程示意如圖1所示。

圖1 SOA功能開發流程示意圖
服務化的設計需要從用戶需求出發,對新功能的需求開發內容進一步剖析,包括用戶場景分析(Use Case)、對標分析、法規需求、分段場景分析(Segment Case)、功能設計需求、用例和法規對應需求映射等,將對用戶的價值點進行提煉,全面以用戶為中心,定義滿足用戶使用場景的功能目標需求。
根據需求分析結果,結合對標車型功能設計方案、新技術供應商方案及自身項目開發經驗,對涉及的子系統進行詳細的功能交互設計。分析SOA功能策略設計,描述系統間交互的需求,對強相關的子系統進行分層設計,對配合的子系統進行能力要求,為子系統服務化設計作鋪墊。功能實現設計需要研究子系統劃分的合理性,在車云一體SOA服務化的設計理念下,考慮之前的功能域劃分和子系統劃分是否需要合理化更新。
子系統設計需滿足以下要求:①研究將功能設計階段產生的需求映射到相應的SOA軟件組件,對軟件模組進行SOA軟件架構分層設計,依據模組的功能交互設計定義內部軟件組件SWC及其服務接口,服務接口及其數據類型的設計需符合AUTOSAR;②研究從多個功能的FR整合出重疊及類似的需求,形成SOA軟件服務接口表和映射關系,考慮服務接口表與下游網絡通信設計和數據庫生成的關聯關系;③形成SOA服務開發及實現的詳細規范,內容包含面向服務介紹、服務設計與實現、服務通信技術、服務測試與分析等,詳細說明整車和云端服務開發的各項技術要求、軟件架構實現SOA的原理和機制、通信的相關技術、測試的方法和分析過程等;④研究文檔的可塑性和可讀性,對同步架構工具建模的兼容性以及更新迭代的便利性;⑤考慮SOA與非SOA的子系統設計的兼容性,以及典型服務化的覆蓋程度和服務化進程的規劃。
SOA服務化設計需在多個功能點進行拓展開發,特別是適合服務化的車身域、座艙域及網聯域,是初期服務化的重點覆蓋內容,是智能駕駛和部分實時性低的新能源功能點。其中,車身域包含外部燈光、內部燈光、雨刮洗滌、車窗天窗、座椅、后視鏡、方向盤、門&鎖、空調、喇叭等;車輛控制域包含車輛模式、低壓能量管理、遠程診斷、整車綜合控制等;部分座艙智駕網聯包含各類典型HMI(信息顯示、車輛設置、人工智能)、導航娛樂、網聯服務,以及典型的智駕預警和泊車場景等。
關于功能和對應的功能點,在服務化設計過程中,主要研究其需求分析文檔、SOA功能設計、SOA軟件設計、通信設計、SOA服務接口文檔數據庫、PV建模可行性、軟件/配置/通信的數據庫生成可行性、不同的部署實現路徑。
所有的流程和設計內容要能映射到架構建模工具中去,形成平臺化的數據成果,并導出支持下一步軟件實現的標準化數據庫文件,從而定義實現標準化組合服務和原子服務,形成面向服務的分層式中央集成式域控平臺[4]。如圖2所示。

圖2 標準化組合服務和原子服務定義示意圖
車云一體化服務部署技術路線如圖3所示。

圖3 車云一體化服務部署技術路線圖
車云一體化服務部署技術則是需要依托車輛功能設計前期所提煉出的SOA服務[5]進行場景引擎和大數據分析的車云一體化設計,包括云端接口設計和遠程原子微服務設計。車云一體化服務部署技術方案示意如圖4所示。

圖4 車云一體化服務部署技術方案示意圖
用戶或工程設計人員可通過Web端、手機APP、車機端自定義期望場景的條件和執行項,并讓車輛在相應條件下實現車身、車輛控制、能量管理等方面的功能,讓更多的人可以利用車上基礎功能的重新排列組合,達到高效產生的新功能,用以適配多變的新場景需求的目的。場景引擎用于實現與多端的連接、同步、解析、執行場景腳本,包括與之相關的功能仲裁、回滾以及通知等周邊功能。研究場景引擎可以將部分上層用戶體驗相關的車輛控制邏輯預留給用戶進行編輯,同時也方便開發人員后臺對一些固化或推薦的場景快速更新迭代,從云端快速(Flash Over the Air,FOTA)刷寫至車端,做到千人千面和常用常新。
大數據分析服務化,設計將相關數據組合并上傳云端分析,數據包含法規數據、工程數據、診斷數據、用戶使用功能數據等。
1)法規數據方面主要是針對新能源法規要求網聯上傳國家平臺的信息進行服務化設計和融合,挑選適合形成原子服務的專一信息數據,根據不同時期或車型更新迭代的法規需求形成組合服務,將此類組合服務標記為可變配置型服務,便于量產階段應用軟件通過配置工具便可更新迭代。
2)工程數據方面和法規數據的定義方式相似,制定的工程數據采集不同的數據的使用用途,可以建立大數據模型,對車輛的動態標定提供大量的可靠數據支撐,對智能駕駛方面有較大意義。
3)診斷數據方面用以太網DoIP代替傳統的CANFD/CAN進行診斷調用,提升云端對車端診斷的數據量和速度,診斷指令的觸發可以是根據故障服務信息的調用,也可以是后臺的主動診斷需求。
4)用戶使用數據是將用戶的各類HMI操作定義為服務并進行融合,在云端后臺通過調用服務知曉用戶的使用習慣,對數據的編排知曉哪些功能點是用戶常用的,哪些設置項是大眾偏愛的,哪些內容是大家不常使用的,對于整車廠對未來車型的設計規劃、新功能的需求分析、已開發功能的需求變更有較大意義。
將場景引擎和大數據服務化作為車云一體服務化的設計目標,將服務實現到車輛端的域控制器和云端中。在車輛端研究以中央計算單元作為服務實現的硬件載體,搭載符合AuotoSAR CP和AP的基礎軟件作為軟件平臺[6],將設計導出的ARXML作為服務實現的輸入,將設計的服務部署到中間件和上層的應用軟件中,達成車端服務部署的目標。在云端研究服務的消費和部分網聯服務的部署,以及場景引擎的編輯平臺和同步平臺,實現車端和云端的業務融合,真正意義上實現車云一體和智能網聯化汽車量產落地。
以面向服務的車云一體化服務部署技術開發,全面提升新一代電子電氣架構,中央域控計算性能、網絡通信帶寬、架構功能安全性、通信信息安全性等性能,推動車云一體化平臺部署產業化進程,對擺脫國外Tier1設計商的技術捆綁和設計依賴,支撐汽車領域“智能化、網聯化、共享化”實現具有重要意義。