c語言中間件

Ⅰ 嵌入式c語言重點知識點

嵌入式C語言重點知識點

嵌入式linux

嵌入式Linux 是將日益流行的Linux操作系統進行裁剪修改，使之能在嵌入式計算機系統上運行的一種操作系統。Linux做嵌入式的優勢，首先，Linux是開放源代碼;其次，Linux的內核小、效率高，可以定製，其系統內核最小隻有約134KB;第三，Linux是免費的OS，Linux還有著嵌入式操作系統所需要的很多特色，突出的就是Linux適應於多種CPU和多種硬體平台而且性能穩定，裁剪性很好，開發和使用都很容易。同時，Linux內核的結構在網路方面是非常完整的，Linux對網路中最常用的TCP/IP協議有最完備的支持。提供了包括十兆、百兆、千兆的乙太網絡，以及無線網路，Token Ring(令牌環網)、光纖甚至衛星的支持。

移植步驟：

1.Bootloader的移植;

2.嵌入式Linux操作系統內核的移植;

3.嵌入式Linux操作系統根文件系統的創建;

4.電路板上外設Linux驅動程序的編寫。

WinCE

WinCE是微軟公司嵌入式、移動計算平台的基礎，它是一個開放的、可升級的32位嵌入式操作系統，是基於掌上型電腦類的電子設備操作系統，它是精簡的Windows 95，Win CE的圖形用戶界面相當出色。WinCE是從整體上為有限資源的平台設計的多線程、完整優先權、多任務的操作系統。它的模塊化設計允許它對於從掌上電腦到專用的工業控制器的用戶電子設備進行定製。操作系統的基本內核需要至少200K的ROM。

一般來說，一個WinCE系統包括四層結構：應用程序、WinCE內核映像、板級支持包(BSP)、硬體平台。而基本軟體平台則主要由WinCE系統內核映像(OS Image)和板卡支持包(BSP)兩部分組成。因為WinCE系統是一個軟硬體緊密結合的系統，因此即使CPU處理器相同，但是如果開發板上的外圍硬體不相同，這個時候還是需要修改BSP來完成一個新的BSP。因此換句話說，就是WinCE的移植過程主要是改寫BSP的過程。

Android

Android 是一個包括操作系統，中間件以及一些重要應用程序的專門針對移動設備的層次結構的軟體集。Android 作為一個完全開源的.操作系統，是由操作系統Linux、中間件以及核心應用程序組成的軟體棧。通過 android SDK 提供的 API 以及相應的開發工具， 程序員可以很方便的開發android平台上的應用程序。其整個系統由應用程序，應用程序框架，應用程序庫，Android運行庫，Linux內核(Linux Kernel)五個部分組成。Android操作系統內置了一部分應用程序， 包括電子郵件客戶端、SMS程序、日歷、地圖、瀏覽器、通訊錄以及其他的程序，值得一提的是這些所有的程序都是用java編寫的。

移植的主要的工作是驅動，硬體抽象層的移植。為了更好地理解和調試系統，也應該適當地了解上層對硬體抽象層的調用情況。

TinyOS

TinyOS是一個開源的嵌入式操作系統，它是由加州大學的伯利克分校開發出來的，主要應用於無線感測器網路方面。程序採用的是模塊化設計，所以它的程序核心往往都很小，一般來說核心代碼和數據大概在400 Bytes左右，能夠突破感測器存儲資源少的限制。TinyOS提供一系列可重用的組件，一個應用程序可以通過連接配置文件(A Wiring Specification)將各種組件連接起來，以完成它所需要的功能。

嵌入式實時操作系統(RTOS)

在工業控制、 軍事設備、航空航天等領域對系統的響應時間有苛刻的要求，這就需要使用實時系統。當外界事件或數據產生時，能夠接受並以足夠快的速度予以處理，其處理的結果又能在規定的時間之內來控制生產過程或對處理系統作出快速響應，並控制所有實時任務協調一致運行的嵌入式操作系統。故對嵌入式實時操作系統的理解應該建立在對嵌入式系統的理解之上加入對響應時間的要求。

FreeRTOS

FreeRTOS是一個迷你操作系統內核的小型嵌入式系統。作為一個輕量級的操作系統，功能包括：任務管理、時間管理、信號量、消息隊列、內存管理、記錄功能等，可基本滿足較小系統的需要。FreeRTOS任務可選擇是否共享堆棧，並且沒有任務數限制，多個任務可以分配相同的優先權。相同優先順序任務的輪轉調度，同時可設成可剝奪內核或不可剝奪內核。

FreeRTOS 的移植主要需要改寫如下三個文件。

1.portmacro.h

2.port.c

3. port.asm

μTenux

μTenux基於ARM微控制器平台，對uT最適用於ARM Cortex M0-M4系列的微控制器，代碼開源、免費，是一個功能強大的搶占式實時多任務操作系統。μTenux除具有實時嵌入式操作系統的一般特性：可移植性，可固化，可裁剪等特性以外，它還具有如下優點：

(1)微內核。無MMU， ROM/RAM佔用量小，所佔ROM最大60KB，最小10KB;RAM最大12KB，最小2KB;

(2)開源免費;

(3)支持所有32位ARM7/9和Cortex M系列的微控制器;

(4)可配置多達到256個任務以及140個任務優先順序;

(5)有良好的商業支持， T-Engine論壇進行總的維護。

移植主要包括：晶元系統時鍾移植，外設移植和通用輸出/輸入埠的移植以及看門狗模塊移植。由於考慮到內核代碼的重要性以及其在整個移植中的重要意義，且為了整個系統有更好的實時性，可選用匯編語言編寫操作系統的啟動代碼。

VxWorks

VxWorks系統提供多處理器間和任務間高效的信號燈、消息隊列、管道、網路透明的套接字。實時系統的另一關鍵特性是硬體中斷處理。為了獲得最快速可靠的中斷響應，VxWorks系統的中斷服務程序ISR有自己的上下文。VxWorks實時操作系統由400多個相對獨立的、短小精煉的目標模塊組成，用戶可根據需要選擇適當模塊來裁剪和配置系統，這有效地保證了系統的安全性和可靠性。系統的鏈接器可按應用的需要自動鏈接一些目標模塊。這樣，通過目標模塊之間的按需組合，可得到許多滿足功能需求的應用。

移植過程可以參考網路上一些BSP代碼，BSP的英文全稱為board support package，即板級支持包，它的作用是針對特殊的硬體平台，為VxWorks內核提供操作的介面。

μClinux

嵌入式Linux作為一個開放源代碼的操作系統，以價格低廉、功能強大又易移植的特性正在被廣泛應用，μClinux是專門針對沒有MMU的處理器而設計的嵌入式Linux，非常適合中低端嵌入式系統的需求。 在GNU通用公共許可證的授權下，μClinux操作系統的用戶可以使用幾乎所有Linux的API函數，不會因為沒有內存管理單元MMU而受到影響;而且，μClinux在標準的Linux基礎上進行了適當的裁剪和優化，形成了一個高度優化的、代碼緊湊的嵌入式Linux，體積小了，但是仍然保留了Linux的大多數的優點，比如穩定性好、強大的網路功能、良好的可移植性、完備的文件系統支持功能、以及標准豐富的應用程序介面API等，可以支持類似ARM7TDMI等類型多的小巧玲瓏的中央處理器。

eCos

eCos中文翻譯為嵌入式可配置操作系統或嵌入式可配置實時操作系統。適合於深度嵌入式應用，主要應用對象包括消費電子、電信、車載設備、手持設備以及其他一些低成本和攜帶型應用。eCos是一種開發源代碼軟體，無任何版權費用。 eCos最大的特點是模塊化，內核可配置。如果說嵌入式Linux太龐大了，那麼eCos可能就能夠滿足要求。它是一個針對16位、32位和64位處理器的可移植開放源代碼的嵌入式RTOS。和嵌入式Linux不同，它是由專門設計嵌入式系統的工作組設計的。eCos具有相當豐富的特性和一個配置工具，後者能夠讓你選取你所需要的特性。

eCos的軟體分了若乾的模塊，移植工作主要在他的hal層進行，所謂hal(硬體抽象層)就是把和硬體相關的軟體湊到一起。

μC/OS-II

μC/OS-II是一個完整的、可移植、可固化、可裁剪的佔先式實時多任務內核。μC/OS-II絕大部分的代碼是用ANSI的C語言編寫的，包含一小部分匯編代碼，使之可供不同架構的微處理器使用。其結構小巧簡潔且支持搶占式的多任務調度與管理。此實時操作系統管理任務數多達64個，且提供內部程序存儲器管理、系統運行時間管理、多任務實時調度與管理等功能。由於它的作者佔用和保留了8個任務，所以留給用戶應用程序最多可有56個任務。賦予各個任務的優先順序必須是不相同的。這意味著μC/OS-II不支持時間片輪轉調度法。μC/OS-II為每個任務設置獨立的堆棧空間，可以快速實現任務切換。

將μC/OS-II操作系統移植到目標處理器上，需要從硬體和軟體兩方面來考慮。硬體方面，目標處理器需滿足以下條件：

①處理器的C編譯器能產生可重入代碼;

②用C語言可以開/關中斷;

③處理器支持中斷，並且能夠產生定時中斷(通常在10～1000 Hz之間);

④處理器能夠支持容納一定量數據的硬體堆棧;

⑤處理器有將堆棧指針和其他寄存器讀出和存儲到堆棧或內存中的指令。

軟體方面，主要是一些與處理器相關的代碼移植，其分布在OS_CPU.H、OS_CPU_C.C和OS_CPU_A.ASM這3個不同的文件中。

Ⅱ Linux環境下C開發_linux搭建c語言開發環境

一：C語言嵌入式Linux工程師的學習需要具備一定的C語言基礎，C語言是嵌入式領域最重要也是最主要的編程語言，通過大量編程實例重點理解C語言的基礎編程以及高級編程知識。包括：基本數據類型、數組、指針、結構體、鏈表、文件操作、隊列、棧等。

二：Linux基礎Linux操作系統的概念、安裝方法，詳細了解Linux下的目錄結構、基本命令、編輯器VI,編譯器GCC，調試器GDB和Make項目管理工具,ShellMakefile腳本編寫等知識，嵌入式開發環境的搭建。

三：Linux系統編程重點學習標准I/O庫，Linux多任務編程中的多進程和多線程，以及進程間通信(pipe、FIFO、消息隊列、共享內存、signal、信號量等)，同步與互斥對共享資源訪問控制等重要知識，主要提升對Linux應用開發的理解和代碼調試的能力。

四：Linux網路編程計算機網路在嵌入式Linux系統應用開發過程中使用非常廣泛，通過Linux網路發展、TCP/IP協議、socket編程、TCP網路編程、UDP網路編程、Web編程開發等方面入手，全面了解Linux網路應用程序開發。重點學習網路編程相關API，熟練掌握TCP協議伺服器的編程方法和並發伺服器的實現，了解HTTP協議及其實現方法，熟悉UDP廣播、多播的原理及編程方法，掌握混合C/S架構網路通信系統的設計，熟悉HTML,Javascript等Web編程技術及實現方法。

五：數據結構與演算法數據結構及演算法在嵌入式底層驅動、通信協議、及各種引擎開發中會得到大量應用，對其掌握的好壞直接影響程序的效率、簡潔及健壯旅瞎性。此階段的學習要重點理解數據結構與演算法的基礎內容，包括順序表、鏈表、隊列、棧、樹、圖、哈希表、各種查找排序演算法等應用及其C語言實現過程。

六：C、QTC是Linux應用開發主要語言之一，本階段重點掌握面向對象編程的基本思想以及C的重要內容。圖形界面編程是嵌入式開發中非常重要的一個環節。由於QT具有跨平台、面向對象、豐富API、支持2D/3D渲染、支持XML、多國語等強大功能，在嵌入式領域的GUI開發中得到了廣范的應用，在本階段通過基於QT圖形庫的學習使學員可以熟練編寫GUI程序，並移植QT應用程序到Cortex-A8平台。包括IDE使用、QT部件及布局管理器、信息與槽機制的應用、滑鼠、鍵盤及繪圖事件處理及文件處理的應用。

七：CortexA8、Linux平台開發通過基於ARMCortex-A8處理s5pv210了解晶元手冊的基本閱讀技巧，掌握s5pv210系統資源、時鍾控制器、電源管理、異常中斷控制器、nandflash控制器等模塊，為底層平台搭建做好准備。Linux平台包括內核裁減、內核移植、交叉編譯、GNU工具使用、內核調試、Bootloader介紹、製作與原理分析、根文件系統製作以及向內核中添加自己的模塊，並在s5pv210實驗平台上運行自己製作的Linux系統,集成部署Linux系統整個流程。同時了解Android操作系統開發流程。Android系統是基於Linux平台的開源操作系統，該平台由操作系統、中間件、用戶界面和應用軟體組成，是首個為移動終端打造的真正開放和完整的移動軟體，目前它的應用不再局限於移動終端，還包括數據電視、機頂盒、PDA等消費類電子產品。

八：驅動開發拆顫空驅動程序設計是嵌入式Linux開發工作中重要的一部分，也是比較困難的一部分。本階洞租段的學習要熟悉Linux的內核機制、驅動程序與用戶級應用程序的介面，掌握系統對設備的並發操作。熟悉所開發硬體的工作原理，具備ARM硬體介面的基礎知識，熟悉ARMCortex-A8處理器s5pv210各資源、掌握Linux設備驅動原理框架，熟悉工程中常見Linux高級字元設備、塊設備、網路設備、USB設備等驅動開發，在工作中能獨立勝任底層驅動開發。

以上就是列出的關於一名合格嵌入式Linux開發工程師所必學的理論知識，其實，作為一個嵌入式開發人員，專業知識和項目經驗同樣重要，所以在我們的理論學習中也要有一定的項目實踐，鍛煉自己的項目開發能力。

Ⅲ C語言介紹

一、C語言的 歷史

C語言由丹尼斯·里奇（Dennis Ritchie）於1972年在位於美國的AT&T（美國電話電報公司）貝爾實驗室發明。C語言借鑒前輩語言的功能和優點，並且克服了它們存在的問題。可以說C語言是對當時現有語言的一次改進和總結，創造出一種在那個時代更加優秀的編程語言。直至當前，C語言還是一種比較重要的編程語言，在比較流行的編程語言排行榜上常年霸榜前幾名，經久不衰。很多計算機專業都是以C語言作為第一編程入門語言，可見C語言的影響和重要性。

圖一 編程語言趨勢&2021排行榜(部分)

二、C語言的特點

C語言是一種中級編程語言，相對於低級語言匯編，高級語言Java等現代語言。C語言可以直接訪問內存，分配內存，與硬體設備交互，具有低級語言的特點；相對於現代的面向對象編程，C語言是一種面向過程語言，面向過程語言也稱為結構化程序設計語言。通俗的講，面向對象編程是把對象當做一個基本編程單位/個體；面向過程編程，把一些功能劃分成一個單元稱之為函數，程序的執行就是函數順序逐步的執行。

三、C語言的應用

C語言有很多方面的應用。首先，C語言發明者使用C語言編寫了Unix操作系統。Linux操作系統也是使用C語言開發出來的。現代很多基礎軟體是使用C語言開發的，比如我們常用的wps辦公軟體等等桌面應用軟體，如果你仔細觀察，你可能發現平時電腦上使用的很多應用就是使用C語言開發出來的，是不是有點小驚訝。可見C語言的應用是很普遍的。C語言應用的領域有系統內核、驅動、基礎應用、桌面應用等等。不過有些領域並沒有使用C語言，Web開發並沒有使用C語言，然而，Web伺服器、中間件使用C語言開發是比較司空見慣的。

我們可以列舉日常使用的軟體有哪些是使用C語言開發的。谷歌瀏覽器部分使用C語言開發，一些規模比較大的軟體，並不是使用單一的編程語言開發出來。QQ、微信PC端也是使用CC++開發。還有wps等等，很大一部分日常使用的PC軟體都是使用CC++開發的。軟體開發領域使用的軟體應用有更多是使用CC++開發出來的。

Ⅳ 如何在c++定義一個學生類以實現平均成績的計算和查詢功能

一．中間件的定義與作用
1.什麼是中間件？
圖片摘自公眾號「筋斗雲與自動駕駛」
筆者在交流中發現，不同的人對中間件的理解並不一樣，甚至可以說，到現在，這個概念還是模糊不清的。比如：
（1）有的人認為中間件僅指位於OS內核之上、功能軟體之下的那部分組件，為上層提供進程管理、升級管理等服務；而有的人則認為中間件還應包括功能軟體和應用軟體中間的那部分（參見上圖）。按茅海燕的說法，前者是「通用中間件」，而後者是「專用中間件」。本文中提到的「中間件」，若不做專門說明，便特指「通用中間件」。
（2）有一些人提到的自動駕駛中間件，包括了AUTOSAR（又分為AUTOSAR CP和AUTOSAR AP），還有一些人口中的中間件，特指ROS2、Cyber RT、DDS等。
（3）未動科技VP蕭猛認為，「中間」一詞是相對的，當有多層堆疊的時候，每一層都是其上下兩層的中間層，因此，在用「中間件」這個詞的時候，我們需要特別指明它究竟位於「哪兩層之間」。按蕭猛的說法，當我們稱「ROS/ROS2 為中間件」時，其含義與 「AUTOSAR AP為中間件」並不是對等的關系。
(4)Vector產品專家蔡守群說，他理解的中間件，「是給App開發提供功能支撐的，對外是沒有功能表徵的；但是站在操作系統內核的角度，中間件跟App並沒有本質的區別」。
2.中間件的作用
汪浩偉說：「專用中間件原本是應用程序的一部分，只是很多公司做自動駕駛都需要用到，就被抽象出來了。」
那麼，它究竟有什麼用？
畢曉鵬認為，自動駕駛中間件最主要的作用是：對下，它能夠去適配不同的OS內核和架構；對上，它能夠提供一個統一的標准介面，負責各類應用軟體模塊之間的通信以及對底層系統資源的調度。
據畢曉鵬解釋，前者，使開發者們無需考慮底層的OS內核是什麼，也無需考慮硬體環境是什麼，即不僅實現了應用軟體與OS的解耦，也實現了應用軟體與硬體的解耦；而後者則確保了數據能夠安全實時地傳輸、資源進行合理的調度。
為什麼要通過中間件來支持軟硬體解耦？畢曉鵬解釋道：
我開發一個應用軟體，其中很多內容都是與具體應用邏輯無關的，包括數據通信、通信安全、系統資源調度等，比如，有十個進程需要數據交互，完全沒有必要在十個程序的軟體代碼里各自進行實現和配置。針對這種情況，我們就可以把重復的部分抽象成一種服務，單獨封成一層東西（這就是中間件），並提供統一的庫、介面和配置方法，供上層去調用。這樣的話，有一部分人專門去做中間件的，而做上層應用的人也不需要考慮跟底層交互的事情。
舉例說，如果要做一個自動泊車系統，它有各個模塊或業務邏輯獨立的不同軟體，在進行通信、數據交互，或者調用底層資源時，只需要中間件的一個介面就可以實現，其他事情不需要考慮，這樣開發人員就可以專注於自己的業務邏輯。
又比如，一個攝像頭需要感知前面的車道線、紅綠燈等，開發人員就專門做紅綠燈和車道線檢測演算法，與外界的數據交互只需要使用中間件的通信服務（例如訂閱攝像頭信息，發布檢測結果），而不必關心數據從哪裡來、發給誰。
Nullmax紐勱科技系統平台總監苗乾坤博士在此前的一篇文章中寫道：
「晶元算力大幅增長，攝像頭像素呈翻倍之勢，激光雷達出現在更多新車規劃上……沒有誰能夠斷言車上的感測器應該有多少，又或者是將來的汽車還會增加哪些硬體，但所有人都知道硬體的變化將會來得更加猛烈。
「所以我們也可以看到，汽車對軟硬體架構的要求也越來越高，既要能滿足當下的需求，還要具備相當的前瞻性、兼容性和擴展性，能夠支持接下來軟硬體升級換代、增減模塊的需求。而自動駕駛的中間件，就正是這樣一個可以按需調整、滿足各樣需求的現代溫室。
「在早期開發中，中間件可以化整為零，將巨大的軟體工程分解成若干小任務，分散解決。在後期應用時，它又可以化零為整，像拼積木一樣，根據需求將一個個模塊組合成一個整體，嚴絲合縫。」
在春節前的一場直播中，東軟睿馳產品銷售總監安志鵬說，在軟硬體解耦、模塊化管理後，再遇到問題，就不用整個系統都改，只改相對應的部分就行了。這樣，軟體的可復用程度就極大地提升了，同時，驗證的工作量也會減少許多，整體開發效率也會因此提升。
相反，沒有中間件的話，應用層就得直接調用操作系統的介面，後期要是換了操作系統，應用層的代碼和演算法可能就要推倒重來。
簡言之，中間件通過對計算平台、感測器等資源進行抽象，對演算法、子系統、功能採取模塊化的管理，並提供統一介面，讓開發人員能夠專注於各自業務層面的開發，無需了解無關細節。
按東軟睿馳產品銷售總監安志鵬的說法，搞AUTSOAR這樣的中間件，並不是只對OEM有利，「零部件供應商的選擇面也大了——應用做好了，下面的軟體、晶元可以選好幾家供應商的，要比傳統的開發模式快很多，因而，零部件供應商也是受益者」。
用蕭猛的話說，中間件最直接的好處就是「為上層屏蔽底層的復雜性」，軟體開發人員可以忽略晶元、感測器等硬體的差異，從而高效、靈活地將上層應用及功能演算法在不同平台上實現、迭代、移植。蕭猛認為，中間件可以看做是自動駕駛應用背景下的一項「新基建」。
（圖片摘自馮占軍博士的《AUTOSAR對基礎軟體開發是喜還是憂？》一文。AUTOSAR只是中間件的一種，但這里寫的「AUTOSAR開發優勢」基本也適用於其他中間件。）
不過，站在開發者的角度看，中間件的意義也未必全部是正面的。如馮占軍博士在《AUTOSAR對基礎軟體開發是喜還是憂？》一文中就提到了如下兩點：
底層軟體工程師變成了工具人，「只要你去點點滑鼠，用工具配合就可以了」，很多原本由自己做的測試也改由供應商來做，進而導致工程師的成就感嚴重降低；時間久了，工程師從0到1開發的能力也會降低。
（圖片摘自馮占軍博士的文章。盡管文章說的是Autosar,但實際上這些問題在ROS等其他中間件的使用過程中也會存在。）
對軟體工程師來說，中間件造成的「能力退化」這一問題幾乎是無解的。但馮占軍博士認為，「如果這個中間件在開發過程中，有使用公司的工程師深度參與，提出需求並一起實施，會好一些」。
此外，殷瑋在一篇文章提到，使用AUTOSAR這樣的中間件，Tier 1們應該是很不情願的，「因為不到增加了成本，還有可能逐步淪為硬體生產商」。但這個也不能說是中間件的鍋，在軟體定義汽車大大趨勢下，這幾乎是必然的。
二．常見的基本概念
1. AUTOSAR CP 與 AUTOSAR AP
在所有的中間件方案中，最著名的非AUTOSAR莫屬了。
嚴格地說，AUTOSAR並非特指由某一家軟體公司開發出來的某款操作系統或中間件產品，而是由全球的主要汽車生產廠商、零部件供應商、軟硬體和電子工業等企業共同制定的汽車開放式系統架構標准。不過，在實踐中，各公司基於AUTOSAR標准開發出來的中間件也被被稱為「AUTOSAR」。
當前，AUTOSAR可分為Classic Platform和Adaptive Platform兩個平台，兩者分別被簡稱為AUTOSAR CP與AUTOSAR AP。
簡單地說，AUTOSAR CP主要跑在8bit、16bit、32bit的MCU上，對應傳統的車身控制、底盤控制、動力系統等功能，如果涉及到自動駕駛的話，AUTOSAR CP可能無法實現；而AUTOSAR AP主要跑在64bit以上的高性能MPU/SOC上，對應自動駕駛的高性能電子系統。
嚴格地說，AUTOSAR CP並不只是個「中間件」，它是相當於「OS內核+中間件」的一套完整的「操作系統」。 AUTOSAR CP定義了基本的上層任務調度、優先順序調度等。
在基於分布式架構的ADAS功能中，AUOTSAR CP便是最常見的「操作系統」。在AUTOSAR的生態形成後，很多晶元廠商的MCU上標配的就是AUTOSAR CP，主機廠沒有什麼選擇權。
由於分布式架構下的晶元主要是MCU，因此，便有了「AUTOSAR CP主要跑在MCU上」的說法。
在分布式架構下，不同的功能對應著不同的MCU，而每一個MCU上都需要跑一套AUTOSAR CP，若感測器的類型比較多，則僅ADAS相關功能就需要很多套AUTOSAR CP，那怎麼收費呢？
常規的做法是：根據MCU的類型來收費——如果MCU是兩個異構的MCU，那AUTOSAR CP就按兩套來收費；如果MCU是同構的，那AUTOSAR CP就按一套來收費。
隨著EE架構從分布式向集中式演進、晶元由MCU向SOC演進，計算量及通信量成數量級地上升，另外，多核處理器、GPU、FPGA以及專用加速器的需求，還有OTA等，都超出了AUTOSAR CP的支持范圍。
（圖片摘自安志鵬的直播課）
2017年，為更好地滿足集中式架構+SOC時代的高等級自動駕駛對中間件的需求，AUTOSAR聯盟推出了通信能力更強、軟體可配置性更靈活、安全機制要求更高的AUTOSAR AP平台。
需要強調的是，不同於AUTOSAR CP自身已經包含了基於OSEK標準的OS，AUTOSAR AP只是一個跑在Lunix、QNX等基於POSIX標準的OS上面的中間件——它自身並不包含OS。
結合aFakeProgramer於2020年發表在CSDN上的《為什麼要用AP？Adaptive AutoSAR到底給企業提供了一些什麼？》一文及東軟睿馳安志鵬在2022年春節前的一場直播中講的內容，AUTOSAR CP與AUTOSAR AP最主要的區別有如下幾點：
1）.編程語言不同——AUTOSAR CP基於C語言，而AUTOSAR AP基於C++語言；
2）.架構不同——AUTOSAR CP 採用的是FOA架構（function-oriented architecture），而AUTOSAR AP採用的則是SOA架構（service-oriented architecture）；
3）.通信方式不同——AUTOAR CP採用的是基於信號的靜態配置通信方式（LIN\CAN...通信矩陣），而AUTOSAR AP採用的是基於服務的SOA動態通信方式（SOME/IP）；
4）.連接關系不同——在AUTOSAR CP中，硬體資源的連接關系受限於線束的連接，而在AUTOSAR AP中，硬體資源間的連接關系虛擬化，不局限於通信線束的連接關系；
5）.調度方式不同——AUTOSAR CP採用固定的任務調度配置，模塊和配置在發布前進行靜態編譯、鏈接，按既定規則順序執行，而AUTOSAR CP則支持多種動態調度策略，服務可根據應用需求動態載入，並可進行單獨更新。
6）.代碼執行和地址空間不同——AUTOSAR CP中，大部分代碼靜態運行在ROM，所有application共用一個地址空間，而在AUTOSAR AP中，應用載入到RAM運行，每個application獨享（虛擬）一個地址空間。
這些區別，帶給AUTOSAR AP的優勢有如下幾點——
1）.ECU更加智能：基於SOA通信使得AP中ECU可以動態的同其他ECU同其他ECU進行連接，提供或獲取服務；
2）.更強大的計算能力：基於SOA架構使得AP能夠更好地支持多核、多ECU、多SoCs並行處理，從而提供更強大的計算能力；
3).更加安全：基於SOA架構使得AP中各個服務模塊獨立，可獨立載入，IAM管理訪問許可權；
4).敏捷開發：Adaptive AUTOSAR服務不局限於部署在ECU本地可分布於車載網路中，使得系統模塊可靈活部署，後期也能靈活獨立更新（FOTA）；
5).高通信帶寬：可實現基於Ethernet等高通信帶寬的匯流排通信；
6).更易物聯：基於乙太網的SOA通信，更易實現無線、遠程、雲連接，方便部署V-2-X應用。
（圖片摘自東軟睿馳）
當然了，在某些方面，AUTOSAR AP與AUTOSAR CP相比是有一些「劣勢」的。比如，AUTOSAR CP的時延可低至微秒級、功能安全等級達到了ASIL-D，硬實時；而AUTOSAR AP的時延則在毫秒級，功能安全等級則為ASIL-B，軟實時。
上述區別也導致了兩者應用領域的不同：AUTOSAR CP一般應用在對實時性和功能安全要求較高、對算力要求較低的場景中，如引擎控制、制動等傳統ECU；而AUTOSAR則應用在對實時性和功能安全有一定要求，但對算力要求更高的場景中，如ADAS、自動駕駛，以及在動態部署方面追求較高自由度的信息娛樂場景。
盡管AUTOSAR AP有種種優點，但總的來說，它目前還不夠成熟——主要是信息安全及UCM等模塊不成熟。量產車上裝AUTOSAR AP的不少，但主要用在娛樂場景，真正用在自動駕駛場景的還很少。
此外，由於SOC+MCU組合的現象會長期存在，因而，在今後相當長一段時間內，AUTOSAR AP都不可能徹底取代AUTOSAR CP——最常見的分工會是，需要高算力的工作交給AUTOSAR AP,而需要高實時性的工作則交給AUTOSAR CP。
（圖片摘自超星未來）
2.ROS 2
ROS是機器人操作系統（Robot Operating System）的英文縮寫，原生的ROS本是機器人OS，並不能直接滿足無人駕駛的所有需求，用作自動駕駛中間件的是ROS 2。
ROS 2與ROS 1的主要區別如下：
（1）.ROS 1主要構建於Linux系統之上，主要支持Ubuntu；ROS 2採用全新的架構，底層基於DDS(Data Distribution Service)通信機制，支持實時性、嵌入式、分布式、多操作系統，ROS 2支持的系統包括Linux、windows、Mac、RTOS，甚至是單片機等沒有操作系統的裸機。
（2）.ROS 1的通訊系統基於TCPROS/UDPROS，強依賴於master節點的處理；ROS 2的通訊系統是基於DDS，取消了master，同時在內部提供了DDS的抽象層實現，有了這個抽象層，用戶就可以不去關注底層的DDS使用了哪個商家的API。
（3）.ROS運行時要依賴roscore，一旦roscore出現問題就會造成較大的系統災難，同時由於安裝與運行體積較大，對很多低資源系統會造成負擔；ROS2基於DDS進行數據傳輸，而DDS基於RTPS的去中心化的通信框架，這就去除了對roscore的依賴，系統的穩定性強，對資源的消耗也得到了降低。
(4).由於ROS 缺少Qos機制，topic的穩定性與質量難以保證；ROS2則提供了Qos機制，對通信的實時性、完整性、歷史追溯等功能有了支持，這便大幅加強了框架功能，避免了高速系統難以適用等問題。
不過，ROS2的QoQ配置較為復雜，目前主要是國外一些專業的大學或實驗室在使用,國內僅有極少數公司在嘗試;此外，ROS 2的生態成熟度遠不如ROS,這也給推廣應用帶來了不便。
跟AUTOSAR AP一樣，ROS 2也是跑在soc晶元上、用於滿足高等級自動駕駛的需求的。不過，蕭猛在去年的一批文章中卻特別強調：當我們稱 「ROS/ROS2 為中間件」時，其含義與 「AUTOSAR AP為 中間件」並不是對等的關系。
蕭猛的文章稱：
當我們說 AutoSar是中間件時，這個中間件是很明確的 L.BSW層語義，即處於計算機OS與車載ECU特定功能實現之間，為 ECU功能實現層屏蔽掉特定處理器和計算機OS相關的細節，並提供與車輛網路、電源等系統交互所需的基礎服務；
ROS/ROS2 是作為機器人開發的應用框架，在機器人應用和計算機OS之間提供了通用的中間層框架和常用軟體模塊(ROS Package)，而且， ROS團隊認為這個框架做得足夠好，可以稱作操作系統（OS）了。
ROS 2盡管在功能上跟AUTOSAR AP有不少重疊之處，但兩者的思路是不一樣的：
（1）.從表現形式上看，AUTOSAR AP首先是一套標准，這個標準定義了一系列基礎平台組件，每個平台組件定義了對應用的標准介面，但沒有定義實現細節，和平台組件之間的交互介面（這些部分留給AUTOSAR AP供應商實現）；ROS2則從一開始就是代碼優先，每個版本都有完整的代碼實現，也定義有面向應用標准API介面。
（2）AUTOSAR AP從一開始就面向ASIL-B應用；ROS 2不是根據ASIL的標准設計的，ROS 2實現功能安全的解決方案是，把底層換為滿足ASIL要求的RTOS和商用工具鏈(編譯器）。
ROS 2「過不了車規」似乎已成為一個很廣泛的行業共識。但在蕭猛看來，ROS2本來就不是為實時域設計的，如果一定要把實時性要求高的車輛控制演算法運行在 ROS2中，「那是軟體設計的錯誤，而不是ROS2的問題」。
蕭猛認為，只要能補齊 L.BSW層所需要完成的所有功能、補齊 A 軸所有切面要求的特性，ROS 2就能用於自動駕駛量產車。如前段時間剛拿到采埃孚等多家巨頭投資的Apex.AI公司基於ROS 2定製開發的Apex.OS就已經通過了最高等級的ASIL D認證。
蕭猛說：「這實際上是基於 ROS 2的架構去實現一套 AUTOSAR AP 規范。這可以成為一個單獨的產品，投入時間+人+錢可以開發出來，只是看有沒有必要，值不值得」。
在具體的實踐中，ROS 2跟AUTOSAR AP存在直接競爭關系——盡管對用戶來說，並不存在嚴格意義上的「二選一」問題，但通常來說，若選了ROS 2，就不會選AUTOSAR AP了；若選了AUTOSAR AP，就不會選ROS 2了。
3. CyberRT
Cyber RT是網路Apollo開發出來的中間件，在Apollo 3.5中正式發布。Cyber RT和ROS2是比較像的， 其底層也是使用了一個開源版本的DDS。
網路最早用的是ROS 1,但在使用的過程中逐漸發現了ROS 1存在「若ROS Master出故障了，則任何兩個節點之間的通信便受到影響」的問題，所以就希望使用一個「沒有中間節點」的通信中間件來代替ROS 1，那時還沒有ROS2，所以自己去做了一個Cyber RT。
為了解決 ROS 遇到的問題，Cyber RT刪除了master機制，用自動發現機制代替，這個通信組網機制和汽車網路CAN完全一致。此外，Cyber RT的核心設計將調度、任務從內核空間搬到了用戶空間。
（圖片出處：https://blog.csdn.net/xhtchina/article/details/118151673）
其相對於其他系統，Cyber RT的一大優勢是，專為無人架駛設計。網路已將Cyber RT開源，某互聯網巨頭的自動駕駛團隊使用的中間件便是網路開源出來的Cyber RT。
Cyber RT跟ROS 2之間也存在競爭關系。
在談到AUTOSAR AP、ROS 2與Cyber RT這些中間件的關系時，Vector產品專家蔡守群的解釋是：
「不需要很機械地去分類，你可以把AUTOSAR AP, ROS和Cyber RT都想像成一個提供一組中間件的超市，用戶可以按需從不同的超市購買，並不是說從一個超市買過一個中間件，就不能從其他超市買了。
蔡守群說：AUTOSAR AP中也包含了對ROS介面的支持。說不準哪天ROS和Cyber RT就會加入AUTOSAR AP的組件，或者 AUTOSAR AP會引入Cyber RT的組件。
4.DDS（通信中間件）
（1）什麼是DDS？
在自動駕駛領域，中間件的功能涉及到通信、模塊升級、任務調度、執行管理，但其最主要的功能就是通信。當前市場上，無論是Cyber RT還是 ROS，基本上90%的功能就是通信，狹義上說就是通信中間件。
通信中間可以分成開源和閉源的兩種。開源的為OPEN DDS、FAST DDS、Cyclone等，閉源的就RTI的DDS和Vector的SOME/IP。DDS的全稱為Data Distribution Service ，指一種數據分發服務標准，由對象管理組織(OMG)制定。
DDS能夠實現低延遲、高可靠、高實時性的數據融合服務，能夠從根本上降低軟體的耦合性、復雜性，提高軟體的模塊化特性。高等級自動駕駛現在基本上都在探索依靠DDS來解決異構通信、低時延等CP解決不了的挑戰。
融合了DDS的汽車軟體能夠更好地運行在下一代汽車的體系架構中，更能降低開發的成本、縮短研發的時間，更快地將產品推向市場。
（2）DDS與ROS 2、AUTOSAR AP之間的關系
ROS 2和Cyber RT的底層都使用了開源的DDS，將DDS作為最重要的通信機制。但也有自動駕駛公司的工程師認為，DDS可以起到替代ROS 2的作用，站在用戶的角度看，兩者之間其實存在「二選一」的關系。
AUTOSAR CP里一直沒有包含跟DDS有關的東西，但AUTOSAR AP在 2018年3月的最新版（版本18-10）里開始支持DDS標准。將DDS與AUTOSAR AP結合使用，不僅可以保證和擴展AUTOSAR AP系統內部互操作性的功能，而且還可以將其開放給來自不同的生態系統（即ROS 2）。
從工程角度來看，將AUTOSAR和DDS結合起來的最大優勢是，功能域和網路拓撲不再是對手，而是車輛中的盟友。網路拓撲結構能夠更好地適應車輛的物理約束，功能域在物理車輛的頂部提供了一個靈活的覆蓋層，這就是所謂的分區體系結構。
當然，DDS僅是通信中間件的一種。關於各類通信中間件之間的異同，我們將在本系列的第二篇做更詳細的闡釋。
三．AUTOSAR AP的地位正在弱化？
盡管AUTOSAR是當下最有名的自動駕駛中間件，但《九章智駕》在對諸多中間件廠商們的調研中得出一個結論：AUTOSAR在產業鏈中的地位可能正在弱化。 當然了，那些專注於AUTOSAR系統的廠商們並不認同這一觀點。
我們在上文已經提到，隨著EE架構從分布式向集中式演進、MCU被SOC取代，CP AUTSAR被AUTOSAR AP、ROS 2和Cyber RT等取代已是大勢所趨，在下文，我們主要談的是「AUTOSAR AP的地位會不會弱化」。
2021年12月中旬，兩家AUTOSAR發起公司大陸集團、豐田聯合採埃孚、捷豹路虎、沃爾沃、海拉等多家汽車行業龍頭企業宣布投資車載操作系統初創公司Apex.AI，而Apex.AI的主力產品Apex.OS則是基於ROS 2發展起來的。
拿到了Apex.AI公司15%股權的采埃孚方面在接受媒體采訪時說：「這意味著，我們可以為客戶提供AUTOSAR AP的替代方案。」
盡管AUTOSAR AP已經有了標准，但還沒有落地。安波福、采埃孚、大陸這些公司提供的方案，仍然是基於AUTOSAR CP標準的介面。事實上，越來越多的OEM不太想完全用AUTOSAR去解決智能駕駛操作系統的問題。
不僅特斯拉沒有用AUTOSAR AP,國內的幾大造車新勢力也沒有用(他們用的是AUTOSAR CP+DDS)。甚至，連一些正在轉型的傳統車企也沒打算用AUTOSAR AP。
從產業鏈中各方的反應來看，AUTOSAR AP「地位不穩」的原因主要有以下幾個：
1．使用成本太高
馮占軍博士在《AUTOSAR對基礎軟體開發是喜還是憂？》一文中透露，AUTOSAR的費用通常是「幾百萬起」，並且，針對不同的域控制器、不同的晶元需要「重復收費」，一般小廠根本吃不消。「可能還沒有什麼產出，幾百萬就花出去了」。
除購買成本高外，畢曉鵬和蕭猛都提到，AUTOSAR前期的學習難度很大、學習成本也非常高。為了學會如何使用AUTOSAR,企業甚至不得不專門培訓一批人,如果受培訓的人臨時離職了，那培訓費用就打了水漂。
2.效率不高
畢曉鵬認為，AUTOSAR AP的配置非常多，它是通過配置加上一部分代碼去實現自己的功能，但配置多了之後，效率不高，而且代碼臃腫。
3.靜態部署與動態部署的理念沖突
畢曉鵬博士提到，AUTOSAR AP其實是從AUTOSAR CP發展而來的，AUTOSAR CP是靜態部署，只適用於相對簡單的業務邏輯和功能，其代碼是固化的，有點像以前的功能手機——功能無法改變，不可能往裡面再加一個APP；但AUTOSAR AP有點像現在的智能手機，軟體開發人員開發一個APP，跨平台就可以用不同手機上了，這種動態部署的理念和之前的靜態部署概念不甚相同，而其方法論卻是基於靜態部署衍生而來的，因此在實踐層面會遇到不少問題。
4.無法滿足智能網聯的需求
由於雲端跟車端所使用的操作系統不一樣，AUTOSAR只能負責車內的通信，不能支持車端到雲端的通信，因而無法支持車路協同場景（車端跟雲端的通信，是通過MQTT、kafka等中間件來實現的）。除此之外，AUTOSAR能否兼容車輛網聯化中需要用到的數據平台、通信平台和地圖平台，也存在很大的疑問。
畢曉鵬說，在發現了這些問題後，有一些OEM開始逐漸放棄AUTOSAR架構，「轉而自己去研發一套更適合動態部署、成本較低的新型軟體架構」。
傳統車廠是從使用CP過來的，所以在慣性上，他們可能還會考慮AP是否適合智能駕駛，但慢慢地也在嘗試轉型。如奧迪和TTTech合作做的通信中間件——zFAS，也沒有採用AP。
不同於AUTOSAR CP已經是非常標准化的東西，大家用起來沒什麼問題，AUTOSAR AP現在的標准也不是很完善，每年也在更新，具體AP能發展成什麼樣，這個誰也不知道，大家更多也是觀望的態度。
畢曉鵬認為，AUTOSAR標准並不能很好地支撐自動駕駛應用和創新的發展，因此，我們有必要建立一套更適合中國智能駕駛發展、且自主可控的技術架構和生態體系。
蕭猛認為，由於從AUTOSAR CP到AUTOSAR AP一脈相承，一些已經對AUTOSAR形成路徑依賴的公司會堅持使用AUTOSAR AP,但在經歷過招人難、開發周期長等教訓之後，他們有可能轉向ROS 2。
當然，以AUTOSAR為主業的公司，顯然不會認可上述「涉嫌唱衰」AUTOSAR AP的觀點的。
比如，Vector蔡守群就認為，AUTOSAR AP只會越來越重要，因為它是順應車載技術不斷發展的一套規范，覆蓋面會越來越廣。
東軟睿馳茅海燕也認為，要將整車域控制器和智駕域控制器合並到統一的中央計算平台上，沒有AUTOSAR AP的支持很難搞定。「不是每家公司都能像特斯拉一樣自己從頭搭建系統的，目前,最好的工具還是AUTOSAR AP」。