軟體定義汽車？Stop Coding＆Start Configuring「GGAI佈道」

AUTOSAR（汽車開放系統架構）是由汽車製造商和供應商在2003年發起的標準化倡議，其目標是為ECU軟體開發一個參考體系結構，以克服現代車輛軟體日益複雜的問題。

這要從為什麼遷移到AUTOSAR開始說起。

有人可能會問，汽車行業真的需要如此複雜的體系結構嗎？隨著對聯網汽車和更安全、更智能的汽車需求的增加，軟體開發瓶頸已經出現。

過去，考慮一輛汽車，它有安全氣囊，發動機控制單元，遠程信息技術，信息娛樂等，所有這些單獨的功能都是由不同的汽車供應商在不同的ecu上實現。

但未來，它們的實現方式不再是獨立的。隨著非標準開發過程的增加，這成為一個更加關鍵的問題。這些形成了AUTOSAR出現的根本原因。

未來，每個部分開發的軟體不再只是針對交付預期的功能，轉而必須考慮它如何影響整個系統。更複雜的是，過去許多功能分布在不同車輛網路(CAN、LIN、MOST等)的不同ecu上。

AUTOSAR分層架構在RTE的幫助下，確保了應用軟體和硬體平台以及驅動程序之間的清晰劃分。這有助於ECU設計方法從編碼到配置模式的轉變。

1、模塊化：汽車軟體的模塊化，使軟體能夠根據電子控制單元及其任務的不同需求進行裁剪。

2、可伸縮性功能：可擴展性保證了通用軟體模塊對不同車輛平台的適應性，防止功能相似的軟體泛濫。

3、可遷移：可轉移性優化了整個車輛的電子架構中可用資源的使用。

4、可重用性：有助於提高產品質量和可靠性，同時降低跨產品線的重複資源投入。

5、標準化：跨製造商和供應商的功能介面標準化，以及不同軟體層之間介面的標準化，這些被視為實現AUTOSAR技術目標的基礎。

AUTOSAR分層架構是AUTOSAR的基本概念，是分離應用程序和基礎硬體。應用程序部分由AUTOSAR軟體組件和連接器組成。軟體組件封裝了每個子系統的功能。

上面的圖顯示了AUTOSAR方法的一個非常簡潔的視圖。

AUTOSAR體系結構主要包括三個軟體層：應用程序層、運行時環境層和基礎軟體層。

基礎軟體是標準化的軟體層，它為AUTOSAR軟體組件提供服務，是運行軟體功能部分所必需的。它本身不完成任何功能任務，並且位於AUTOSAR運行時環境之下，包含標準化和ECU特定組件。

AUTOSAR基礎軟體進一步劃分為服務層、ECU抽象層、微控制器抽象層和複雜驅動層。

MCU抽象層對硬體的訪問通過微控制器抽象層(MCAL)路由，以避免從更高級別的軟體直接訪問微控制器寄存器。

MCAL是一個特定於硬體的層，它確保基本軟體組件的標準介面。它對MCU外圍設備進行管理，並為基本軟體的組成部分提供了與MCU無關的值。MCAL實現通知機制，以支持向不同進程分發命令、響應和信息。

複雜的設備驅動程序，此層用於其他層上未找到的複雜函數。這一層直接訪問微控制器(MCU)，例如：注入控制、電量值控制、位置增加檢測等。對於處理複雜的感測器和執行機構，這是一種特殊的功能和時間要求。

CDD（Complex Device Drivers）通過直接訪問特定於uC的中斷和外圍設備，實現複雜的感測器評估和執行器控制。

ECU抽象層，此層介面與MCAL(包括外部設備驅動程序)，提供對外設和設備的訪問，不論它們是在微控制器(MCU)內部還是外部，以及用於與微控制器(MCU)介面的API(埠插腳、介面類型)。它使得上層軟體層獨立於ECU硬體布局。

虛擬功能匯流排(VFB)，VFB是AUTOSAR所提供的基本軟體的所有通信機制和基本介面的抽象集合，即獨立於技術的層次。當為具體系統定義AUTOSAR軟體組件之間的連接時，VFB將允許在早期開發階段對它們進行虛擬集成。

運行環境(RTE)，從AUTOSAR軟體組件的角度來看，RTE在特定的ECU上實現了VFB功能。然而，RTE可以儘可能地將此任務委託給基礎軟體。

AUTOSAR區分了三種類型的介面：

AUTOSAR Interface：AUTOSAR介面是一個通用介面，它派生自任何SWC的埠。

AUTOSAR介面由RTE提供，充當SWCs之間或SWC與ECU固件(IoHwAb，複雜驅動程序)之間的介面。例如，SWC可以通過這些介面讀取輸入值並編寫輸出值。

Standardized AUTOSAR Interface：標準化的AUTOSAR介面是由AUTOSAR標準預定義的特殊AUTOSAR介面。

SWCs使用這些類型的介面訪問AUTOSAR服務，AUTOSAR服務由服務層的BSW模塊提供，例如ECU狀態管理器或診斷事件管理器。

Standardized Interface：標準化介面是AUTOSAR標準在C語言中將其預定義為API的介面。它用於ECU中的BSW模塊之間、RTE與操作系統之間或RTE與BSW模塊Com之間。

AutoSAR工作流

不過，對於面向自動駕駛，上述AUTOSAR經典平台已經不太適合，尤其是需要軟體架構的靈活性來進行空中更新，這個時候就有了AUTOSAR自適應平台（AUTOSAR Adaptive Platform）。

自適應AUTOSAR並不是經典AUTOSAR的繼承者；它不會取代它。相反，它是定義ECU軟體及其如何在ECU硬體上運行的另一種方法。

為什麼需要另一個AUTOSAR平台？

因為，對於自動駕駛，軟體架構的需求已經發生了根本性的變化，比如需要更多的環境感知、多感測融合、遠程通訊、軟體定期更新等等。

而基於AUTOSAR經典平台設計軟體體系結構，只能運行在小型專用硬體上(就計算能力而言)，不需要修改，通信是使用傳統的汽車匯流排網路，這些都不能很好地滿足自動駕駛、聯網汽車的需求。

這時候，靈活性就是關鍵要素。

通過AUTOSAR自適應平台，軟體功能之間的通信是面向服務的。此外，底層通信不再基於CAN或其他使用專用協議的經典汽車匯流排系統，而是基於乙太網。

作為面向服務的中間件層，它定義了應用程序通信的實際方式。例如，您不再需要在代碼行為中直接定義循環觸發器時間。

此外，使用AUTOSAR經典平台，軟體組件之間的通信是硬連接的，並由AUTOSAR運行環境(RTE)實現，RTE將通信從體系結構級別轉換為ECU級別。它通過解析靜態宏並將它們轉換為適當的基本軟體調用來實現這一點，例如，將它們包裝成匯流排消息。

如果您想要在運行時替換軟體，這是行不通的。自適應平台通過實現面向服務的通信體系結構，克服了硬連接通信的缺點。

同時，對於自動駕駛系統來說，特別是在感測器數據處理方面，是在Linux系統上開發的。我們需要操作系統提供的所有靈活性，包括靈活的內存分配、線程處理等等。

我們不想——也可能不能——放棄這種靈活性，因為我們必須為專門的ECU操作系統編譯代碼。因此，AUTOSAR自適應平台是基於POSIX介面的。

去年11月，AUTOSAR發布了最新版本的自適應平台（Release 18-10），具有數據分發服務(DDS)標準的完整網路綁定。隨著新版本的發布，汽車製造商現在可以使用DDS實現AUTOSAR自適應框架，並開發L4/5高等級自動駕駛系統。

這意味著可用於量產的通信框架，提供這些複雜系統所需的可靠性、可擴展性和性能，它使開發人員能夠動態配置平台，以支持不同車型平台的各種操作模式和硬體功能。

在AUTOSAR自適應平台中，DDS組件被優化為端到端數據共享，幾乎不需要定製集成。因此，基於DDS的技術為汽車製造商提供了一個以數據為中心的互操作框架，支持常用的所有操作系統和處理器體系結構，從而消除了複雜的集成和安全挑戰。

汽車製造商還可以利用AUTOSAR規範之外的其他技術，包括基於雲的和後端系統，以及汽車行業中常見的附加組件，如MatLab和Simulink，以及DSpace、Linux和QNX平台。

要知道，讓自動駕駛汽車上路不僅僅是技術和演算法的問題。

（以下內容為豐田在去年發布的面向自動駕駛和高性能計算ECU的新軟體平台的挑戰的相關演示內容。）

備註：本文部分內容來自高通公司首席軟體工程師Manjunath Savadatti的發表文章

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！