從工程師的角度看AUTOSAR

“軟件定義汽車”的火熱帶動了工程師們對于汽車電子軟件熱烈地討論。不曾想到，隱藏在控制器內部，默默地發揮著作用的汽車電子軟件，如今備受矚目。本人畢業到現在，一直在汽車行業做軟件，切身感受到一系列的變化。寫軟件的方法在變，行業技術標準在變，和OEM合作模式在變，還有敏捷轉型等等。10多年前，有人認為汽車行業是夕陽產業，IT是朝陽產業。現在看來，無論是汽車還是IT，依然朝氣蓬勃，更令人欣喜的是，這兩個產業的融合為未來的發展帶來了新的契機。

1

開端-OSEK/VDX

OSEK/VDX標準的出現代表著汽車電子軟件標準化的開端，該標準的構成：實時的操作系統（OSEK OS），通訊子系統（OSEK-COM）和網絡管理系統（OSEK-NM）。

在OSEK出現之前，軟件生產商們僅依靠自身積累，寫出的軟件五花八門，水平參差不齊，有些甚至沒有清晰的軟件層次結構，這樣寫出的軟件質量堪憂，并且可維護性是很差的。有了OSEK標準的借鑒和指導，很多軟件生產商依照OSEK標準開發出了自己的軟件產品。像汽車行業的Tier1，提供軟件與硬件整套完整方案是常態，Tier1自研的完善可靠的軟件產品也是其核心競爭力之一。

OSEK OS是實時操作系統，可以滿足大多數汽車控制器的任務調度要求。另外其可移植性和可擴展性很高，可以輕松移植到新MCU平臺。對于實時性要求，除了要有好的操作系統，也需要程序設計者合理地規劃常規任務和中斷處理程序，如果任務阻塞或執行時間過長，會極大的影響正常任務的調度。近年來，軟件系統的實時性和確定性執行也不斷地在演進。確定性操作系統，再配合邏輯執行時間（LET）模型，可提供更高級別的功能安全機制。

下圖摘取自OSEK標準文檔，圖中展示了OSEK/VDX的基本結構和各組件間的關系。這也算是典型的帶網絡通信的汽車ECU軟件的最小系統了。

在2000年左右，Tier1的ECU軟件自研比例非常高，對軟件產品的掌控力也相當強，底層軟件和應用層軟件都由Tier1完成開發。OEM和Tier1之間軟件開發的合作方式，主要是由OEM向Tier1分發書寫格式和內容非常規范化的需求文檔，有些做到好的，則采用格式化的語言來描述需求，甚至是偽代碼的書寫形式。

V模型開發流程（瀑布模型的進階）是當時的主流。按自上而下的過程遞交交付物，并在相對應層級依次驗證，是V模型開發的特點。V模型開發迭代周期長，一般與功能交樣時間相匹配。迭代次數少，一般5到6次迭代后，基本就到SOP量產了。當時汽車ECU功能定義固化早，每個ECU功能數量較少，需求開發相對穩定，在當時看來，V模型的開發流程是非常合適的。

2

進階-AUTOSAR

上文提到了OSEK，因為它與AUTOSAR頗具淵源，AUTOSAR的部分設計也參考了OSEK標準。OSEK是汽車軟件標準化的第一步，它影響的范圍是ECU層面。OEM和Tier1之間穩定的合作方式也已經形成。但汽車軟件標準化的進程并沒有停下來。

這里插句題外話。OEM和Tier1的這種合作模式下，Tier1的系統與軟件能力變得格外的強，另外OSEK的標準化，總線設計的標準化，也讓各個廠家設計的ECU之間的連通變得簡單。在這個背景下，Tier1對整車電子電器架構的影響很大，依靠Tier1的能力，攢起一套主流的電子電器架構也成為可能。行業頭部的整車廠，Tier1，芯片等其他環節的供應商，對電子電器架構的構想也一定程度上推動著行業的發展。

上文有提到過，OEM需要花費相當大的精力來書寫需求說明書，以描述ECU的應用層功能，完成后交予Tier1來開發軟件。而隨著車上的ECU數量不斷增加，信號復雜程度增加，傳統的開發方式顯露出了開發復雜，維護困難等弊端。讓汽車電子系統開發更靈活，更有效率，成為汽車工程師的目標。AUTOSAR的誕生旨在達成這個目標。AUTOSAR從一開始就志在整體汽車電子開發的標準化。所以AUTOSAR所涵蓋的方法論，虛擬功能總線，元模型與模板工具，軟件架構及模塊，所有這些工作都導向這一目標。可以毫不夸張的說，AUTOSAR是汽車工程師的智慧結晶。

AUTOSAR的推出，OEM與Tier1之間的合作方式有了微妙的變化。在介紹新的合作方式之前，這里 先介紹下AUTOSAR的核心概念：虛擬功能總線（VFB）。

下圖引用自AUTOSAR標準。如圖，VFB之上描述的是軟件組件（SWC），以實現軟硬分離。OEM著重于系統層面的設計，包含SWC的設計及它們之間的通信方式。VFB是虛擬總線，真實的情況是它們以Flexray，CAN總線方式通信，或者是ECU的內部通信。而這些都會在整車開發流程中的SWC部署，網絡設計中體現。

在了解以上的基本概念后，再來講講OEM和Tier1的合作方式有哪些。

方式一：

OEM：以AUTOSAR的標準方法設計系統及軟件架構，并以ARXML的形式導出，同時負責應用層軟件SWC的開發。

Tier1：以AUTOSAR的標準方法完成基礎軟件的配置與生成，復雜驅動軟件的開發，最終軟件的集成與版本釋放，并提供硬件平臺。

特點：雙方關注自己負責的軟件部分，耦合部分不多，溝通成本最低。

方式二：

OEM：基本與方式一相同，但OEM自己不開發應用層軟件。

Tier1：除了方式一提到的內容，還包括應用層軟件的開發。

特點：軟件開發的工作都落到了Tier1身上，但應用層軟件需求溝通的成本較高。

方式三：

OEM：除了系統及軟件架構設計以外，OEM還負責應用層及底層軟件開發，包括最終軟件的集成與釋放。

Tier1：僅配置MCAL部分的軟件。

特點：OEM包攬了大部分的軟件工作，Tier1的價值僅在于提供硬件平臺（包括MCAL軟件）。

方式四：

OEM：按自身的方式設計系統架構及發布需求，但并不是AUTOSAR的標準方法，應用層軟件開發為備選。

Tier1：以AUTOSAR的標準方法完成底層軟件，應用層軟件為備選，取決于OEM是否提供基于標準接口的應用層軟件。

特點：此方式用到了AUTOSAR軟件標準架構和模塊，但缺少了精髓的系統設計部分。

另外，AUTOSAR也改變了軟件工程師需要的技能和工作方式。手工代碼漸漸轉向基于模型的開發，底層功能模塊依靠工具配置及代碼生成。驗證軟件的方式也更多樣，模型仿真，SIL，HIL等等。

3

突破-AP AUTOSAR

從本節開始，AUTOSAR會標注CP （Classic Platform） 和AP （Adaptive Platform），以示區分。

CP AUTOSAR標準其實也在不停的演進中，Ethenet， Crypto， E2E， SOME/IP等等也是在4.X的版本中才出現。基本上，有新的技術需要運用，AUTOSAR就有推出相應的標準。

但CP平臺畢竟有它的局限性，對于高算力的應用場景無能為力。AP AUTOSAR的出現正是應對高性能計算平臺的需要，AP AUTOSAR的定位是運行于POSIX操作系統之上的中間件。設計者也不乏考慮，AP平臺和CP平臺在一個架構下共存的問題。所以它與生俱來，具備和CP AUTOSAR有良好的交互能力。

高性能計算平臺必然是未來電子電器架構的主角，已經有不少架構師們設想把它運用到多域控制器，以及中央計算平臺當中。AP AUTOSAR在高性能計算平臺的作用不可小覷。這可以從AP AUTOSAR的設計細節得出。

ARA：COM提供應用層之間標準且可靠的通信方式，統一化的通信方式有助于避免由于通信機制的不同造成的設計缺陷。同時支持事件驅動和輪詢模式也是它的主要特點，因實時應用程序通常基于輪詢模式，而支持此模式可以保證前后級數據傳遞式樣的一致，避免不必要的上下文切換。

ARA：EXEC主控應用程序的生命周期，設計者同時也考慮了功能安全方面的設計，例如狀態恢復，資源管理，確定性執行等機制。

ARA：SM 收集應用程序的各種異常狀態并適時地調整相應的應用程序功能，為功能安全提供有效的機制。

ARA：PHM提供監控應用程序的能力，并在檢測到異常后執行恢復動作。它支持幾種典型的任務監測機制：alive， deadline， logical supervision。

其他AP AUTOSAR包含的API及Service組件不在這里 一一介紹。可以看出，APAUTOSAR除了提供基本的應用層開發平臺中間件，同時也有不少功能安全上的考慮，其中一些機制可以有效的應對ISO26262軟件部分“Freedom from interference”中提出的相關需求。

AP AUTOSAR在這樣一個復雜的環境下誕生，工程師們必定對其賦予厚望，從它的設計思路來看，AP AUTOSAR不但吸取了現有成熟的技術，同時也有所創新，引入互聯網技術的同時也不乏考慮其適用性和可靠性。如今AP AUTOSAR剛經歷了幾個版本，對比CP AUTOSAR從萌芽到茁壯成長的過程，AUTOSAR的未來必定可期。

— END—

《淺談汽車電子軟件》專輯

進入汽車行業是偶然，但選擇做軟件是必然。聽一位前輩說過，“你永遠別指望一個人能把一件不喜歡的事做好”，軟件技術一直是我的愛好，汽車也是我熱愛的，慶幸當初的自己能選擇這個行業。現在閑暇時寫一些分享性的文章，希望和行業中的友人們一起成長。

作者：Paulfrank