易特馳全棧中間件助力從概念到量產

如何在這些既要又要的需求中，選擇一個合適的技術路徑一直是各家車企的的核心能力。完成一個車輛應用的開發就像寫一個手機應用一樣簡單成為了理想中的終極目標。

在這個目標的驅使下，選擇一款功能強大的中間件至關重要。

總的來說中間件要解決以下主要問題：

1.為應用層提供穩定的SOA架構API

應用層開發者能像手機APP一樣調用標準的API和服務框架接口，即使產品換代了也不需要關心他們是否立馬不能用。這就是SOA的能力，為實現跨域融合等中央計算平臺的發展，高性能SoC產品和中央集中式E/E架構是實現跨域融合的硬件基礎，而面向服務的軟件架構（SOA）則是實現跨域融合的軟件基礎。

在汽車軟件的領域，最佳實現跨域融合的方式是面向服務的架構（Service-oriented Architecture, SOA）。SOA是一種軟件設計方法，其中軟件組件被設計為獨立的服務，可以通過網絡進行通信和交互。在汽車軟件中，SOA的應用可以將各種車輛系統，如發動機管理系統、制動系統和娛樂系統等，分解為獨立的服務組件，使得這些組件可以更加靈活地進行組合和配置，以滿足不同車型和市場的需求。SOA可以提高汽車軟件的可靠性、可維護性和可擴展性，使得汽車制造商可以更加容易地開發和維護各種汽車系統。

SOA有助于提高汽車軟件的開發效率和質量，通過整合已有的軟件模塊，可以避免重復開發和測試，同時可以減少軟件集成帶來的問題和風險，提高軟件的可靠性和安全性。

值得注意的是，傳統汽車軟件開發的中間性工具鏈并不會被取代，剎車、轉向、防爆、車身穩定控制等傳統車控軟件是由單一ECU控制，并不適用于SOA架構，未來仍會通過基于模型仿真和嵌入式的傳統汽車軟件開發方式進行開發。但是由于未來新型的車用軟件需具備跨域能力，因此無法按照傳統單一ECU的開發方式去開發，必須采用SOA架構。

2.高效的調用下層車輛信號

目前大部分車型還是使用CAN的協議，怎么把中間件框架與CAN協議連起來也會遇到復雜的問題，也就是DBC信號映射的難題。

DBC信號示意圖

DBC信號映射生成的痛點分析:

1. 編寫DBC與API映射關系低效繁瑣

在現代汽車工程領域,數據總線通信(DBC)文件扮演著至關重要的角色。這些文件定義了車載網絡中各種信號的屬性,為整個系統的正常運行提供了基礎支撐，行業內已經有成熟的工具來編輯生成DBC。然而,對于大多數工程師來說,編寫與上層API的映射關系無疑是一項繁瑣且令人頭疼的任務，因為上層API的定義是基于車企內部的要求定制的，用到的相關工具鏈也是內部自研的。

編寫映射關系無疑是一個痛苦的過程。工程師需要仔細推敲每個信號定義的格式和內容,如同在茫茫大海中尋找一根針般感到無助和挫敗。即使完成了這項艱巨的任務,接下來還需要小心翼翼地檢查每一個細節,生怕犯一些低級錯誤。這就像是一個永無止境的噩夢,讓人感覺自己就像是一名專業的"MS文員"。不僅浪費了寶貴的工程師時間和精力,也大大增加了項目的開發成本。每個細微的失誤都可能造成嚴重的后果,使整個車載網絡系統陷入癱瘓。因此,迫切需要一種更加高效和可靠的映射關系生成方式,以減輕工程師的負擔,提高整個車載網絡系統的開發效率。

自動化工具，算法以及校驗正確性功能無疑是一個很好的解決方案。通過采用這種方式,工程師可以擺脫半人工編寫映射關系的痛苦,專注于更有價值的工程任務。只有這樣,我們才能真正提升車載網絡系統的開發效率,推動汽車工程技術的不斷進步。

2. DBC信號映射關系缺乏可視化

雖然DBC自身的工具鏈已經很成熟，但業界普遍缺乏可視化的DBC映射關系分析工具。開發者只能依靠文字描述來推測理解各個信號和API的定義,就好比讓一個連螞蟻都捉不住的人去抓野兔一樣,完全是癡人說夢。筆者曾經花費大量時間才搞清楚一個DBC文件和對應的上層API接口,結果第二天就又忘記了大部分內容,效率之低下令人發指。

然而,對于汽車電子領域的開發者來說,能否迅速理解和操作DBC以及API,往往直接決定著項目的進度和質量。若能借助可視化工具,將這些繁瑣的配置信息直觀地呈現出來,必將大大提升開發人員的工作效率。比如,運用漂亮的圖表展示各個信號的數據特性以及對應API的變化,或者提供一個直觀的關系編輯器,讓開發者可以輕松地修改和調試這些關系,無疑會大幅緩解當前映射關系操作的困境。

3. DBC信號映射關系的版本管理困難

在實際應用中,映射關系的版本管理存在諸多問題，需要知道最終生成的文件是由哪個版本的DBC，API版本，映射規則版本以及最終三者經過處理后的產出物的版本等。由于缺乏統一的版本控制機制,當需要追溯之前的文件變更情況時,常常會陷入"大海撈針"般的困境,難以找到準確的歷史記錄。這無疑給后續的系統集成和故障診斷帶來了很多不便。

當前,汽車行業正處于一個關鍵的轉折點。隨著電動化、自動駕駛和連接服務的發展,車載軟件正變得愈發復雜和關鍵。傳統的軟件開發模式已經難以滿足日新月異的市場需求,迫切需要尋找全新的解決方案。ETAS公司正是對這一趨勢高度重視,并在不同領域進行了積極的探索與實踐。值得關注的是,他們在Eclipse開源社區推出了幾個重要的項目,試圖從根本上改變汽車軟件開發的范式。

首先是Velocitas項目,這是一款基于高級語言的應用層開發框架。它旨在簡化復雜的軟件構建過程,使開發人員能夠更加高效地創建車載應用程序。通過Velocitas,工程師可以擺脫底層硬件和操作系統的限制,專注于業務邏輯的實現,大大提高了開發效率。

其次是Kuksa項目,這是一個符合VSS國際標準的車輛模型描述規則。Kuksa建立了一套完整的車輛數據模型,涵蓋了從底層硬件到高層應用的各個方面。利用這個統一的數據模型,不同的軟件組件可以更好地進行集成和協作,極大地減少了系統復雜性。

最后,Leda項目更是令人興奮。這是一個能夠實現"一鍵部署"的解決方案,可以將開發好的軟件快速部署到真實車輛和仿真平臺上。有了Leda,工程師再也不必為復雜的交叉編譯、打包等問題而煩惱,大大提高了軟件驗證的效率。而且,Leda項目團隊還在不斷升級完善,相信不久后就會有更多令人期待的新功能。

ETAS公司在Eclipse開源社區推出的這些項目,無疑為未來汽車軟件開發帶來了新的希望。Velocitas、Kuksa和Leda三大項目分別從應用開發、數據建模和自動化部署等關鍵環節進行了創新,為解決行業痛點提供了有力的支撐。