在不斷發展的汽車技術領域，電子系統標準化和互操作性的需求變得至關重要。隨著車輛集成越來越復雜的軟件功能，諸如 AUTOSAR（AUTomotive Open System Architecture 汽車開放系統架構）之類的框架已成為汽車行業的基礎支柱。AUTOSAR 的歷程不僅展示了標準化工作，還展示了為滿足現代車輛架構和軟件開發范例的需求而不斷發展的過程。AUTOSAR 的起源可以追溯到 2000 年代初，當時主要汽車制造商和供應商認識到開發汽車軟件時采用標準化方法的必要性。它是一個開放、標準化的汽車軟件架構，支持應用軟件和基本車輛功能之間接口的標準化，有助于為所有AUTOSAR成員建立通用的ECU軟件架構。主要目標是解決車輛電子設備日益復雜和電子控制單元 (ECU) 激增帶來的挑戰。

從本質上講，它是一個標準化的開源平臺，可實現現代車輛內各種電子控制單元 (ECU) 之間的無縫通信和集成。它提供了結構化的軟件架構，使汽車制造商和供應商能夠高效協作、縮短開發時間（找元器件現貨上唯樣商城）并提高軟件質量。通過其分層方法，AUTOSAR 簡化了復雜的軟件生態系統，促進模塊化和可擴展性，同時確保不斷發展的汽車領域的安全性和可靠性。

AUTOSAR 旨在為成員提供固有的優勢，以管理日益復雜的 E/E 車載環境，例如復雜 ECU 網絡中功能的輕松集成和交換以及整個產品生命周期的控制。

多年來，AUTOSAR 經歷了多次迭代，每次迭代都旨在完善其架構、通信協議和軟件開發方法。AUTOSAR 發展的重要里程碑包括：

1.

基礎軟件（BSW）堆棧：標準化基礎軟件模塊的開發構成了 AUTOSAR 架構的核心。這些模塊提供了通信堆棧、診斷和操作系統服務等基本功能，確保了不同汽車平臺之間的一致性。

2.

通信協議：AUTOSAR 引入了 CAN（控制器局域網）、LIN（本地互連網絡）和 FlexRay 等標準化通信協議，實現了車輛網絡內 ECU 之間的無縫通信。這些協議在支持實時、確定性通信方面發揮了至關重要的作用，這對于安全關鍵型汽車系統至關重要。

3.

方法和工具：AUTOSAR 制定了開發過程指南，包括軟件設計、配置和集成的方法。此外，圍繞AUTOSAR 的生態系統已擴展到包括各種開發工具、配置編輯器和代碼生成器，從而簡化了汽車制造商和供應商的軟件開發生命周期。

4.

自適應平臺：隨著汽車行業擁抱電氣化、互聯化和自動駕駛等趨勢，對更加靈活和可擴展的軟件架構的需求變得顯而易見。AUTOSAR 通過推出自適應平臺來滿足這些需求，該平臺旨在支持動態軟件更新、無線（OTA）功能和高級駕駛員輔助系統 （ADAS）。

5.

與行業標準集成：AUTOSAR 不斷與其他行業標準和計劃保持一致，包括針對功能安全的 ISO 26262和針對網絡安全的 ISO 21434。通過將這些標準集成到其框架中，AUTOSAR 確保汽車系統滿足最高的安全要求。

AUTOSAR 的初始階段側重于定義分層軟件架構，以促進跨不同車輛領域的汽車軟件的開發、集成和可擴展性。分層架構方法允許關注點分離，并實現軟件組件更大的模塊化和可重用性。經典的 AUTOSAR 平臺在微控制器上運行，分為 3 個主要層；

1.

基本軟件架構（Basic Software Architecture） - It is common to any AUTOSAR ECU.

2.

AUTOSAR 運行時環境（AUTOSAR Runtime Environment）

3.

應用層（Application Layer）

最近，有必要支持可以在硬件或軟件擴展中實現的概念，使 AUTOSAR 能夠配置和利用高級硬件功能，而不受任何特定實現目標的限制。

轉向集中式和區域式 E/E 架構需要 OEM 為其架構上的許多功能更強大的 ECU 規劃更大規模的同步新一代 ECU，這通常與為 OEM 帶來更多軟件以及更多的內部 ECU 開發相一致。

AUTOSAR 自適應平臺的推出是為了支持更多應用程序，例如汽車行業日益可用的高性能計算的功能和靈活性。隨后，經典平臺和自適應平臺的通用功能已轉移到基本標準中，以確保保持互操作性。

雖然 AUTOSAR 自適應平臺擴展了 AUTOSAR 支持的ECU 類型，但 AUTOSAR 經典平臺仍然適用于許多傳統ECU，但專注于將高計算功能和服務整合到中央/區域/域ECU 中并不能完全消除功能相對簡單的 ECU 控制和監視輸入和輸出。Classic Platform 非常適合具有安全相關功能的控制功能，同時支持高達 ASIL D 的可用和網絡安全擴展，以確保免受惡意或系統故障造成的干擾。

經典平臺作為編號版本發布到 4.4.0，其中第一個 4 代表主要平臺版本，概念的更改, 不兼容前代。第二個 4 代表增量版本，其中添加了新概念，這意味著同代標準本身也不完全兼容。最后的 0 代表次要版本，對標準進行澄清和修復，而不是概念更改或添加。該標準的所有 3 部分現已作為年度版本一起發布，即 R20-11，對應于 2020 年 11 月。大多數 OEM 為一代 E/E 架構使用特定版本已成為正常做法，通常是稍后（或有時更早）版本或特定于 OEM 系統設計的一些增強和/或定制。

在最近的版本中，根據 AUTOSAR 創建的目標，我們更加努力地協調經典平臺和自適應平臺之間的架構和功能，從而簡化兩個平臺在生產 E/E 架構中協同工作的部署。

R20-11 版在經典平臺中新增對 ieee802.3 g 規定的以太網10BASE-T1S 的支持，使以太網中的總線拓撲成為可能。經典平臺和自適應平臺都將支持 OSI 模型第 1 層和第 2 層上的這一新擴展。

新增加了以太網喚醒（Ethernet Wakeup On Dataline）功能，擴展了以太網通信棧，結合現有通信功能（如部分網絡）使用符合 OA TC10 的以太網硬件（PHY）。

在車輛網絡狀態管理中，通過動態學習額外路由的可能性，擴展了基于靜態路由的現有 PNC 協調算法。

引入了"入侵檢測系統管理器 "概念，規定了基于 AUTOSAR 的入侵檢測系統 (IDS) 的框架。

此外還定義了車輛運動控制接口、10BASE-T1S、經典平臺靈活性，并針對經典平臺和自適應平臺的交互進行了升級，加強了兩個平臺之間的互動。

R21-11 版在 R20-11 基礎上，進一步定義和增強了經典平臺的功能：

1.

定義了 10BASE-T1S 中支持兩種可用的 HW 解決方案：通過 SPI 的 10BASE-T1S 外部 MAC 控制器和通過 MII 的 PHYs。

2.

增強了 經典平臺靈活性，支持位于應用軟件集群中的軟件組件基于信號和 SOME/IP 的通信--可獨立于主機軟件集群及其通信棧構建。

3.

重新設計與 PNC 相關的 ComM 和 NM，用專用API 代替 ComM 和 Nm。

通過下層組件 MemAcc 和 Mem 擴展了現有內存堆棧，為多個上層模塊提供內存訪問協調，并提供與內存技術無關的內存驅動程序接口，從而支持空中下載（OTA）軟件更新等新用例。

盡管取得了許多成就，但 AUTOSAR 在快速變化的汽車領域不斷發展時也面臨著一些挑戰。一項重大挑戰是在標準化和靈活性之間取得適當的平衡。雖然標準化促進了互操作性和兼容性，但它也會抑制創新并阻礙汽車制造商之間的差異化。另一個挑戰是適應軟件定義車輛日益復雜的情況，以及高級駕駛輔助和自動駕駛系統對人工智能（AI） 和機器學習（ML）算法的日益依賴。AUTOSAR 會不斷發展以支持這些新興技術，同時保持其模塊化、可擴展性和可靠性的核心原則。

如上介紹的，汽車開放系統體系結構（AUTOSAR）是汽車工業遵循的標準，AUTOSAR 分層架構的其中一層是 MCAL（微控制器抽象層）。AUTOSAR 為屬于 MCAL 層的設備驅動模塊提供了非常詳細的規范。通過提供 MCAL 層提供標準化的軟件接口和配置，使中間件軟件（BSW）和應用層獨立于底層硬件平臺。

英飛凌為 AURIX? TC4x 系列微控制器提供了 MCAL 層實現，其符合 AUTOSAR 4.6.0 (R20-11) 的定義，內存驅動程序是符合 4.7.0 (R 21-11) 版本的。英飛凌還為沒有 AUTOSAR 標準的外設模塊提供復雜的驅動程序。

所有MCAL驅動模塊的開發都符合 ISO-26262 Automotive SPICE 3.1 Level 3 和 ISO-21434 中定義的流程。所有源代碼的開發都符合 MISRA C 編程語言和 SEI CERT-C (2016) 編碼標準。

TC4x MCAL 驅動程序提供了完整的源代碼，基于 Tresos 配置工具的配置支持，文檔和演示軟件，使用戶能夠快速入門。

TC4x MCAL 從四個方面進行了軟件提升：

1.

功能安全：避免 ASIL D 實現的額外驅動程序；簡化軟件分區，提供更大的靈活性（ASIL D 域執行）; 簡化系統級安全論證

2.

信息安全：支持強制性網絡安全標準；英飛凌為報告的事件提供網絡安全事件響應

3.

多核虛擬化：啟用對虛擬 ECU 的支持；簡化軟件分區，提供更大的靈活性（多核操作）

4.

產品質量：支持最新標準: ASPICE ver3.1 level 3；避免需要密集的客戶審核

審核編輯 黃宇