AP AUTOSAR的案例
基于案例解析AP AUTOSAR開發流程
本文通過一個應用案例，將整體使用AP AUTOSAR的流程簡單介紹。同時，讀者將理解AP AUTOSAR的幾個基本平臺組件。基于這個案例，讀者可以了解最基礎的AP AUTOSAR開發流程。其中，重點介紹了AP AUTOSAR建模。
1
開發流程
AP AUTOSAR整體開發流程
AP AUTOSAR開發流程：
定義服務：輸出ServiceInterface, 屬于OEM工作范圍。
生成基于Skeleton/Proxy 的Class。使用AUTOSAR供應商工具鏈。
實現SWC和使用目標軟件平臺工具鏈編譯為可執行文件 Executables。
生成Machine Manifest。描述目標硬件和軟件平臺環境。將應用映射到進程。使用AUTOSAR工具鏈。
2
案例：服務定義
將車輛功能拆解為服務的部分在這里就不多講了。我個人認為這個跟業務邏輯強相關，跟IT域的方法論沒什么太大區別。
一個服務接口需滿足SOME/IP的組成，里面包含3部分：Fields，Events，Methods。技術細節請參看SOME/IP介紹。
本文假設一個服務接口RadarFusion。
對于一個SOA服務接口，肯定至少得有一個Provider和可能多個Consumer。
3
使用工具鏈生成Skeleton/Proxy
Skeleton/Proxy是在CM （Communication Management）選擇的基本設計模式。這是軟件設計模式里最常用的幾個設計模式之一。AP AUTOSAR基本上參考了GENIVI的CommonAPI設計。
展開 基于AP AUTOSAR實現功能安全島
目前比較多的國際Tier-1采用AP AUTOSAR在MPU側來實現功能安全島。值得各位同行注意的是，要實現此架構，safety應用需要整個軟件棧支持，從底層OS，標準庫，POSIX庫，BSP，到AP協議棧。他們缺一不可。目前就AP協議棧本身來講，已經有商用解決方案提供ASIL-D等級的EM和PHM。
AUTOSAR Builder—符合AUTOSAR（CP/AP）的嵌入式系統設計工具
AUTOSAR Builder是達索旗下一款基于Eclipse的開放、可擴展工具套件，用于設計和開發符合AUTOSAR標準的系統和軟件。新版本2022x支持AUTOSAR Release R20-11，并且Adaptive code generators 已升級支持AUTOSAR Adaptive R20-11。
Adaptive AUTOSAR 解決方案 INTEWORK-EAS-AP
經緯恒潤 AP 軟件組件架構
- 工具鏈
除軟件組件外，經緯恒潤Adaptive AUTOSAR 解決方案包含完整的 Adaptive AUTOSAR 工具鏈，運行于 PC 機上，實現 AUTOSAR 組件軟件的設計、生成與配置功能。工具鏈包含 AP.Configurator 和 AP.Generator 兩部分，工具鏈示意圖如圖3所示：
圖3. Adaptive AUTOSAR工具鏈方案示意圖
AP.Configurator：AP 產品配置工具， 支持導入、解析、編輯基于 AP 平臺的 ARXML 文件， 完成 Machine、Executable、Instance 等設計開發。支持導入 ODX，并轉化為 ARXML 格式診斷模型。支持配置 SWC 文件，完成 SWC Port 及框架設計。
AP.Generator：AP 產品生成工具，實現組件 API 代碼及 Manifest 配置文件的生成，輸入是標準的 ARXML 和 ODX 文件，生成 C++11 源代碼和 Manifest 配置文件。
經緯恒潤 Adaptive AUTOSAR 應用案例
經緯恒潤 Adaptive AUTOSAR 已廣泛應用到智能駕駛、智能座艙、車身域控及T-box等控制器，助力數十個車型項目開發及量產。
圖5.
展開 
干貨‖新能源智能汽車EE架構--AUTOSAR（AP）SOA特點
200個汽車工程技術“干貨”無償分享請繼續閱讀↓↓↓
本平臺聲明
1、文中材料僅供學習交流，不得用于任何商業目的。未經授權不得在其他公眾號及媒體發布。對于轉載、引用本文內容而引起的民事紛爭、行政處理或其他損失，本網不承擔任何責任。
2、文中部分數據和文字引自媒體、公開文獻及作者在線投稿等方式，版權屬原作者。如有涉及內容、版權等問題。請盡快聯系我們，我們會及時處理。
3、聯系電話:15321663998 郵箱:hb_cao@126.com
2022年4月份培訓
自動駕駛軟件架構開發技術高級培訓班
電動智能網聯汽車電磁兼容（EMC）性能的測試、優化及設計高級培訓班
2022年長期舉辦培訓
車輛極限駕駛技能提升實操技術高級培訓班
在線閱讀經典培訓講義（期待大家轉發和分享干貨知識）
干貨‖新能源動力電池全壽命設計及應用技術培訓系列三
干貨‖新能源動力電池全壽命設計及應用技術培訓系列二
干貨‖新能源動力電池全壽命設計及應用技術培訓系列一
展開 符合AUTOSAR（AP&CP）的嵌入式系統和軟件設計工具
AUTOSAR Builder功能介紹
AUTOSAR Builder 是達索旗下一種基于 Eclipse 的開放性、可擴展工具套件，用于設計和開發符合 AUTOSAR 標準的系統和軟件。2020x版本支持AUTOSAR Classic 4.4.0及AUTOSAR Adaptive R19-03。
圖 1-AUTOSAR Builder工具主界面
從功能層面講，AUTOSAR Builder為AUTOSAR系統開發提供快速、自動化的建模和仿真的手段。
? AUTOSAR Authoring Tool(AAT)-支撐AUTOSAR系統研發
? 對Classic Platform AUTOSAR，支持application software development/system design/basic software configuration/system integration等研發工作。
展開 支持L3+的軟件架構及產品架構
這實際上是基于 ROS2的架構去實現一套 AP AutoSar 規范。這可以成為一個單獨的產品，投入時間+人+錢可以開發出來，只是看有沒有必要，值不值得。
3.2 ROS/ROS2 在 (D.P + L.FW)中的地位
ROS/ROS2 確實實現了一個機器人開發的應用框架并提供了很多基礎組件，大大便利了機器人應用的開發。但是目前的機器人應用都是在一個很小的區域內移動。一般范圍比較大的是倉庫機器人，運動范圍也就在百米數量級，場景也比較單一。所以 ROS/ROS2對機器人開發的支持映射到智能駕駛，多體現在分形遞歸的 EPX 模型的最內層。即短距離內單一場景的感知、規劃和控制執行。其并沒有對復雜的場景的調度(S)和多場景并行下的執行仲裁(A)機制。畢竟還沒有機器人需要從北京走到廣州。
所以作為智能駕駛的軟件開發框架，ROS/ROS2仍然有很多欠缺，但是作為快速原型工具仍然是非常好的選擇。
3.3 關于"中間件"
顧名思義，“中間件”一定是在兩層中間，為上層屏蔽底層的復雜性。計算機軟件架構中有一句名言：“計算機科學領域的任何問題都可以通過增加一個間接的中間層來解決” 。這是軟件架構設計的一個主要的設計哲學，用在了無數地方，也解決了無數的問題。而且“中間”一詞也是相對的，當有多層堆疊的時候，每一層都是其上下兩層的中間層。所以我們說“中間件”的時候，需要指明其上下文，否則容易出現表達與理解的不一致。
當我們說 AP AutoSar 或 CP AutoSar 是中間件時，這個中間件是很明確的 L.BSW 層語義。即處于計算機OS與車載ECU特定功能實現之間，為 ECU功能實現層屏蔽掉特定處理器和計算機OS相關的細節，并實現與車輛網絡、電源等系統交互所需的基礎服務。
展開 基于SOA架構的開發策略詳解
對于SOA來說，是需要在AP Autosar流程下設計從服務定義到服務實例化的整個過程，為了實現在算法和軟硬件調用中的有效通信，就需要設計有效的通信協議，對于SOA來說基礎的通信協議除了Can以外，最基本的就是以太網的通訊設計。
基于Autosar的SOA軟件開發設計詳解
總結
整體上講，面向服務的SOA架構設計主要包含五個步驟：梳理整車功能、規劃SOA架構、服務定義、服務矩陣和ARXML設計、服務驗證和仿真；SOA不是一種具體的技術實現，而是一種模板軟件架構，而AP AUTOSAR則稱是一個模板SOA。如何利用Autosar構建好的SOA模型是我們需要特別關注的。本文詳細闡述了面向服務的SOA軟件設計過程，以Autosar為基礎分析軟件架構及其設計方法、系統配置、硬件抽象、軟件分層等。
SOA=SOME/IP？你低估了這件事 | 第二彈
AUTOSAR Adaptive platform，簡稱AP，一個基于服務理念的中間件，就是個很好的例子。其體現了基于服務的架構思想：運行環境（ara）分成了Foundation和Service兩部分
圖三 AP軟件架構示意
Foundation：
? CM（Communication Management）包攬了節點間&進程間通信
? EM（Execution Management）負責進程控制執行
? REST（RESTful）體現外溝通的連通性
? PHM（Platform Health Management）系統平臺健康管理
? TimeSyn（Time Synchronization）時間同步模塊等； Service：
? SM（State Management）監管了AP上運行的功能組和進程的狀態轉換
? DM（Diagnostic Management）能夠以AAP的粒度進行刷寫和診斷
? NM（Network Management）網絡管理模塊
? UCM（Update and Config Management）主導的應用程序更新、AP自更新以及OS更新的整套更新理念等；
AP作為中間件，需要配合支持POSIX標準的操作系統使用，上層的應用（AAP）會通過ARA運行環境由AP來配置、管理、調度和分配資源。
? 那…AP也是AUTOSAR推出的，和CP有什么關系呢？為什么要引入AP的概念呢？現有的操作系統和架構，比如Android，不能滿足SOA基于服務的實現嗎？
AP和CP屬于AUTOSAR家族，是親兄弟的關系。CP推出的時間比較早，AP則是2017年才正式出現并有了初版AP規范集。
展開 從Adaptive AUTOSAR的角度看SOA
4、Adaptive AUTOSAR與SOA
現有的操作系統和架構，比如Android，不能滿足SOA基于服務的實現嗎？AP也是AUTOSAR推出的，和CP有什么關系呢？為什么要引入AP呢？
? Non-AUTOSAR（信息娛樂）的控制器：占用較大的硬件資源、不具有實時性、運行非車規級的操作系統上（比如Linux、Android）。
? CP AUTOSAR開發出來的控制器：實時性強、消耗資源少、軟件資源固定。
? Adaptive AUTOSAR是一種異構的軟件平臺，可以成為連接Classic AUTOSAR和非實時OS的橋梁。它的特點是：軟實時（毫秒級別），滿足功能安全要求（ASIL-B以上）、更適合于多核的高資源消耗環境、支持動態部署。
AP和CP都屬于AUTOSAR家族，是親兄弟的關系。CP推出的時間比較早，AP則是2017年才正式出現并有了初版AP規范集。正如大家所知道的，目前CP在各類車載ECU的開發實現中占有很大的使用比例，主要是應對嵌入式ECU的開發。這很符合上文所說的一個盒子一個功能的整車分布式E/E架構的需求，明確具體功能后可以精準地控制ECU本身的軟硬件開發，并且CP軟件架構的模塊化方式配合AUTOSAR OS也可以充分滿足一些特定功能對ECU本身運行時的實時性要求。
普通的OS例如Android，在某些場景下不能滿足汽車的功能安全需求。
展開 
從Adaptive AUTOSAR的角度看SOA
4 Adaptive AUTOSAR與SOA
現有的操作系統和架構，比如Android，不能滿足SOA基于服務的實現嗎？AP也是AUTOSAR推出的，和CP有什么關系呢？為什么要引入AP呢？
? Non-AUTOSAR（信息娛樂）的控制器：占用較大的硬件資源、不具有實時性、運行非車規級的操作系統上（比如Linux、Android）。
? CP AUTOSAR開發出來的控制器：實時性強、消耗資源少、軟件資源固定。
? Adaptive AUTOSAR是一種異構的軟件平臺，可以成為連接Classic AUTOSAR和非實時OS的橋梁。它的特點是：軟實時（毫秒級別），滿足功能安全要求（ASIL-B以上）、更適合于多核的高資源消耗環境、支持動態部署。
AP和CP都屬于AUTOSAR家族，是親兄弟的關系。CP推出的時間比較早，AP則是2017年才正式出現并有了初版AP規范集。正如大家所知道的，目前CP在各類車載ECU的開發實現中占有很大的使用比例，主要是應對嵌入式ECU的開發。這很符合上文所說的一個盒子一個功能的整車分布式E/E架構的需求，明確具體功能后可以精準地控制ECU本身的軟硬件開發，并且CP軟件架構的模塊化方式配合AUTOSAR OS也可以充分滿足一些特定功能對ECU本身運行時的實時性要求。
普通的OS例如Android，在某些場景下不能滿足汽車的功能安全需求。
展開 SOA中的軟件架構設計及軟硬件解耦方法論
最終，AP Autosar中的應用軟件通過實時運行環境RTE對傳感器感知目標級數據進行實時的讀取，用于后續的應用軟件的規劃控制和決策控制。
從如上示例可看出，設備抽象具備如下優勢，Sensor&Actuator的變化不會引起平臺軟件和應用軟件的連帶更改，總結起來大致有如下幾種變換導致的軟硬件解耦類型。
對于替換不同型號的感知傳感器，ECU的選型不再受限制于ECU支持的信號分析模式的型號。如NTC和PTC型號的替換，只需要修改位于Device Driver中軟件模塊即可。同一類型的傳感器和執行器模塊可共用某些相同的處理模塊，比如對于側視攝像頭的處理模式，可以直接將對其中一個側視攝像頭的處理算法直接應用于其余三個，而只需要重新對該三個攝像頭的相機參數進行標定即可，如果有部分攝像頭需要更新換代為更高分辨率攝像頭，對于底層驅動軟件和平臺軟件來講也是無需做很大變動的，至少I/O接口形式和數據輸入模式都不用在動，只是在處理圖像的算法模塊需要重新進行調優，比如原來采用的低分辨率處理算法可能無法達到高分辨率處理模塊對其實時性的要求，這時需要研究神經網絡加速模型的優化方式，但是整體的算法架構模型是仍舊不變的。
總結
當前眾多主機廠比較倡導的開發方式是進行平臺化產品開發，而平臺化講求的就是軟硬件解耦的核心思想，采用SOA架構模式則是便于形成產品線和平臺線的分工，產品線負責具體車型項目，平臺線，負責構建技術中臺。新平臺的開發，技術鏈路往往非常長且復雜，分層的架構設計和軟硬件解耦的方式，可很好的便于進行分層測試與驗證，減少集成測試的壓力，問題發現的更充分，也能夠提高版本發布的速度。
展開 經緯恒潤AUTOSAR全面適配芯馳車規芯片，聯合打造全場景國產解決方案
近日，經緯恒潤與車規芯片企業芯馳科技共同宣布，經緯恒潤AUTOSAR系列產品已全面適配芯馳全場景車規芯片，助力芯馳中央網關芯片“網之芯”G9、智能座艙芯片“艙之芯”X9、智能駕駛芯片“駕之芯”V9、高性能MCU“控之芯”E3的應用落地，為市場提供全場景的國產軟硬件解決方案。
強強聯合，打造平臺化、全場景國產解決方案
在軟件和芯片日趨國產化的浪潮下，經緯恒潤自主研發的AUTOSAR產品INTEWORK-EAS全面適配芯馳科技全場景車規芯片，共同構建智能汽車基礎平臺解決方案。未來，雙方將進一步加強戰略協同，深化擴展合作領域，持續為智能汽車行業提供創新性技術應用，共同為中國智能網聯汽車軟硬件解決方案的國產化貢獻自己的力量。
經緯恒潤AUTOSAR & 芯馳科技“網之芯”G9
早在2021年6月，經緯恒潤完成基于芯馳G9X的全棧基礎軟件INTEWROK-EAS-AP&CP適配工作，并完成基于DMS應用實例的車載計算平臺演示系統的研發，后將相關技術經驗成功應用到OEM客戶的量產項目中。
基于G9X的車載計算平臺演示系統
經緯恒潤AUTOSAR & 芯馳科技“艙之芯”X9
2022年8月，經緯恒潤完成基于芯馳X9H的全棧基礎軟件INTEWROK-EAS-AP&CP適配工作，研發推出的SOA演示系統即將正式亮相。
基于X9H的座艙域SOA演示系統
經緯恒潤AUTOSAR & 芯馳科技“駕之芯”V9
2022年10月，經緯恒潤INTEWORK-EAS-AP成功適配芯馳V9硬件平臺，滿足客戶對于新一代智能駕駛輔助系統應用日益增長的需求。
展開 自動駕駛系統設計的那些底層軟件開發中的重點解讀
作者 | Jessie
出品 | 焉知
眾所周知，隨著自動駕駛和智能網聯技術的飛速發展，傳統的汽車開放系統架構CP Autosar已經無法滿足日益復雜的汽車電子系統的功能需求。尤其底層軟件中，針對面向服務架構SOA開發需要使用高性能的處理器，自適應汽車開放系統架構AP Autosar有著不可比擬的優勢。
而應用軟件中，自動駕駛整體架構主要涉及感知、規劃、決策、控制等節點。通過數據或信息的存儲、傳遞及有效及時處理，可以完成感知算法、決策算法、控制算法的整體遞進式集成。數據在采集單元與算法單元之間、每兩個算法節點之間進行傳遞時，都需要經過“數據緩存”和“數據發布”兩個步驟。這一過程就涉及多項自動駕駛底層軟件技術，如內存動態分配、芯片運算能力、芯片實時監控策略。本文將針對這三方面內容進行詳細說明。
功能安全攔路虎：內存分配與訪問
在汽車電子系統的軟件開發標準中，強調需要保證軟件架構要素之間的獨立性，相互之間不能存在干擾。而這類干擾軟件要素的可能原因分為三部分：運算、內存、通信。其中，運算能力涉及運算時序和執行策略。這對開發符合功能安全要求的軟件提出了具體的要求，而這一分析過程無論從難度系數還是工作量上都很大，而“內存分配”和“內存訪問”是非常重要的一個原因。
1）內存分配
內存分配主要存在于自動駕駛底層軟件領域。通常的做法是，數據發布單元向底層操作系統申請適當的內存，數據發布之后釋放內存。在申請內存和釋放內存的過程中，主要有如下三種內存分配方式存在：
如上圖所示，“靜態內存分配”和“堆上內存分配”兩種方式中，其相關技術需要在分配內存空間時，都需要搜索連續且空閑的最小內存分配單元，導致存在時間開銷大、內存碎片化嚴重等問題。
展開 