前言

搞一下新架構下的軟件技術系列會從高層軟件架構出發，從宏觀的軟件技術運用開始，逐步展開每個方面的軟件技術細節，為讀者朋友們提供學習軟件相關技術的平臺。全系將涵蓋軟件架構設計，服務應用設計，中間件技術，模型開發技術等方面進行分享。


全系內容可在《搞一下汽車電子》后臺回復 “系列”，或進入菜單欄 “分享平臺” --> “系列分享”


本系列請點擊：《搞一下新架構下的軟件技術》


所有系列請點擊：《汽車電子系列分享》

汽車ECU發展

首先回顧汽車ECU的發展，從這張圖我們可以看到，從1975年第一代電子電噴控制器開始，汽車ECU發展迅速，ECU的數量與發展度也隨之快速增長。





發展到1985年，已經出現了像變速箱控制器，發動機控制器等，同時也出現了第一代車內網絡總線CAN。接近2000年，更復雜的主動安全控制器，車輛穩定系統控制器，自適應導航控制器等陸續出現。


伴隨著汽車ECU的發展，車內網路總線的技術也在不斷發展，從相對低速的CAN、LIN總線技術發展出更高速的Flexray, 可以到達10M的通信速率。


最近幾年，車內以太網開始應用100-baseT1，1000-BaseT1的以太網技術，從應用場景上是為了滿足自動駕駛以及車聯系網所需的高數據通信的應用需求。


為了滿足復雜的應用功能，相對比較獨立的汽車軟件，也慢慢引入了互聯網的軟件技術，如在工業以太網運行成熟的實時通信技術，互聯網服務架構理念，給汽車軟件帶來了創新的靈感。


在這個背景下，對汽車ECU的發展起到了非常大的推動作用。另外新能源汽車發掘出了新穎的功能，更方便的AI人機交互過程，以及越來越智能的輔助駕駛系統。

獨立單一功能ECU

接下來講一下汽車ECU軟件的發展歷程，一開始汽車上出現的ECU主要是解決單體功能，比如以軟件的方式對電油門噴嘴進行更精確的控制，以達到更好的燃油和動力的效率。對于這類控制器，軟件的架構也是相對簡單的。





微控制器具備一定的外設資源，如果Timer, IO, ADC, PWM。另外它具備一個軟件系統必須的CPU，Program Flash, RAM等。


在這類微控制器系統上可以進行一些基本的任務調度，通過定期的產生時間中斷來觸發周期性的任務調度。任務包括對信號的采集，處理，然后輸出相應功能的信號輸出。





在逐步的發展中，由多個解決單體功能的ECU，它們之間需要有信號的交互，由此衍生出來帶網絡通信，更復雜的ECU，他們之間通過網絡的互聯，將信號收集到功能域控制器，以實現更高級，智能的車輛功能。


比如車身控制器包含了對車上所有車身相關的所有功能，包含有大燈，車窗，雨刮，門鎖等。對于這類ECU，它軟件的復雜度相對較高。





它是基于分層的軟件架構。與硬件之間相關的是硬件驅動層，它稱為MCAL層，是對硬件的適配層。在這之上是抽象層，它的作用將標準軟件模塊與硬件的不同特性進行解耦，以實現標準化軟件模塊設計。在這之上就是典型的系統服務，內存服務，通信服務，IO服務等。


該服務層提供了控制器基礎的底層軟件功能，它們對于控制器來說，需求是相對相似的，ECU模塊之間的軟件復用性很強，很適合做成標準化，可配置的模塊。這也是汽車軟件標準化的前提。


由于軟件模塊的復雜度的提升，對操作系統的要求也相應提升，對操作系統的要求就是需要實時性強，任務調度管理能力強，并且支持高優先級任務搶占的操作系統能力。

汽車軟件標準化的開端 OSEK/VDX

OSEK是德文的縮寫：“Offene Systeme und deren Schnittstellen für die Elektronikim Kraftfahrzeug”
VDX代表：“Vehicle Distributed eXecutive”


在更多ECU控制器出現的同時，每家公司都必須掌握ECU軟件的開發，如果是獨立的ECU控制器，則不需要關注和其他ECU通信協議兼容的問題。


但實際情況下，大多數車輛ECU都需要和其他ECU實現通信，如果是一個通信速率不高，信號數量不大的ECU，可以采用LIN的通信協議。如果通信的數量和速率達到一定程度，就有必要采用CAN通信協議。


通常一輛整車，它的零部件是由不同供應商去提供的，每個供應商開發的軟件必須對外實現相同的通信協議以及管理的策略。汽車軟件標準化的開端就是OSEK/VDK. OSEK/VDK是德文首字母的縮寫，OSEK含義是汽車電子開放式系統及其接口，VDX則是汽車分布式運行系統

OSEK/VDX 目標和動機

動機


OSEK/VDX的動機在于解決ECU基礎與通信部分軟件可以在不同的硬件平臺上重用，快速的移植到新的硬件平臺。


解決由于協議和接口不同造成的各供應商的控制器之間不兼容，開放式系統及其接口的好處也體現在軟件質量的提升和不同供應商合作開發過程中。


目標


提高應用層軟件的可移植性和可重用性。


制定標準化的實時操作系統RTOS，以及處理器之間的通信用到的通信協議棧，以及相同行為的網絡管理策略。


在軟件架構層面實現接口抽象化，應用與硬件解耦。


對于操作系統，通信協議中與網絡管理，ECU有差異的部分進行配置，比如任務的配置，通信信號的配置等，而大多數的軟件實現都是靜態固定的代碼，使得軟件的復用性和可靠性得到大幅度的提升。同時要求架構具有擴展性，方便未來增加新的標準軟件模塊。


下圖描述了工具化實現OSEK標準模塊的過程，開發者通過接口描述語言描述功能接口， 通常包含應用程序接口，網絡信號接口等。接口描述語言和具體的編程語言無關，但它可以作為一個標準化的語言對一個系統進行描述。





這些描述文件可以通過工具進行識別，進而生成不同ECU的動態代碼部分，也叫做配置文件。除靜態代碼和動態代碼部分，一款ECU通常還會有為專用功能開發的軟件模塊，以及解決集成問題的粘連代碼模塊，它們合在一起就組成了完整的項目工程，將它們進行編譯后，即可生成ECU的可執行文件。


以這樣的方式開發出來的軟件具有良好的應用層接口，通信行為，以及系統任務調度策略。

OSEK/VDX 主要的規范

OSEK/VDX主要相關的規范有：


OSEK OS（操作系統）


OSEK COM（通訊）


OSEK NM（網絡管理)

實時操作系統（RTOS）

在講OSEK操作系統之前，我們先介紹下什么是實時操作系統。


如圖所示，在一個Event事件發生后，經過一定的延遲后，觸發相應的函數功能。該函數的執行時間經過嚴格的計算，保證在期限時間內能運行完成。這就是通常對一個實時操作系統的定義。





對這樣一個操作系統，它需要具備一定的調度能力，即該系統能夠滿足在任何情況下，在限定時間內完成對任務的調度。


第二是響應能力，要求系統具備低延遲響應，即使在Worst case下依然能保證這個性能。


第三就是任務過載時的穩定性，即使在發生任務過重而出現過載，無法滿足在限定時間內完成對所有任務的調度的情況下，仍然可以保證高優先級的任務得到調度。

OSEK 操作系統

OSEK操作系統規范就是基于這些要求而制定的，OSEK操作系統最合適運行的硬件環境就是微處理器，在這類系統中，通常需要實現的是實時要求高的應用功能，對外設的要求需要有總線控制器，如CAN, LIN, 以及對數字輸出端口進行操作。


OSEK OS首先定義了標準化的接口。即應用軟件和操作系統之間的接口由統一化的操作系統服務定義，這樣對于不同的處理器，操作系統對外的系統服務都是相同的。


第二就是可擴展性，OSEK OS定義了多種不同的調度機制，不同的RTOS能力分類，使得它適用于各種應用程序和硬件。


第三錯誤檢查，提供開發階段和生產階段所需的錯誤檢查的處理。第三就是應用軟件的可移植性，這就是OSEK的主要目標之一

OSEK Conformance Classes

OSEK支持多級RTOS能力等級劃分，稱為”Conformance Classes”。


主要由三個方面去描述RTOS能力等級，第一個是任務的類別，分基礎任務和擴展任務，它們之間的區別在于基礎任務沒有等待狀態，而擴展任務允許有等待狀態。
第二個差別在于多任務的激活，第三點是具有優先級的多任務調度。


從這三個能力角度，組合成了4種Conformance Classess, BCC1， BCC2, ECC1，還有ECC2。如下圖所示，從RTOS能力上來說，ECC2是具備最高等級的。

OSEK 相關術語

在OSEK OS標準中，有一些常用的術語：


Tasks
Scheduling
Interrupt
Resources
Alarms&Counters
Event
Hook Routines
System Services


下圖展示的是任務的狀態轉換示意圖。

OSEK 通信

第二個主要的OSEK標準是OSEK COM。對于一個典型的網絡，對照參考模型，可以劃分為7層。


OSEK COM主要實現了網絡層，和數據鏈路層的標準實現。OSEK COM在總線通信硬件上設計了標準的設計驅動接口，網絡層實現了標準的總線協議，同時對上層應用也提供了標準的應用程序接口。這樣設計的目的在于為汽車控制器應用軟件提供統一的通信環境，好處是提升了應用軟件的可移植性。





從圖中可以看出，OSEK COM和OSEK NM，OSEK OS有著依賴關系，它們之間需同時配合，以實現ECU的通信功能。

OSEK 網絡管理

對于一個帶網絡通信的ECU，網絡管理是十分重要的，直接影響到整車的使用體驗，網絡管理如果出現故障，可直接引起車輛無法啟動，整車無法休眠等問題。


OSEK網絡管理能有效的管理參與網絡的各個ECU的喚醒和睡眠。該協議主要定義了網絡管理報文，報文定義了每個ECU的狀態，以及睡眠，喚醒意圖的標識位。


在建立通信的過程，相當于建立起環狀的通信鏈路。同時考慮到某個ECU點可能會發生故障而不能繼續參與網絡通信，它也可以識別出這種異常狀態，并且由剩余的ECU，重新建立起環狀的通信鏈路。


網絡管理的目的和職責如圖所示，如激活通信硬件，同步網絡節點同步轉換到睡眠狀態等，同時對網絡進行診斷，網絡出現錯誤后進行恢復等。

汽車開放系統架構 AUTOSAR

OSEK/VDX是一個汽車軟件標準化的開端，而進一步將汽車軟件標準化的就是AUTOSAR。AUTOSAR已經廣泛運用在主流的ECU控制器軟件中。


AUTOSAR和OSEK/VDX的關系相當于， AUTOSAR是OSEK/VDX的繼承和發展，從很多AUTOSAR的標準文檔中，我們可以看到它借鑒了OSEK的協議標準，比如AUTOSAR OS和OSEK OS很多概念都是一致的。


當然AUTOSAR增加了很多新特性，比如Schedule Table, 時間同步，棧監控，內存保護等機制。AUTOSAR的引入在于OSEK定義的標準模塊，僅包含OS, COM, NM，但一個完整的ECU軟件組件還包括內存的處理，標準的外設處理等，進一步將這些軟件模塊進行標準化的詳細設計也是很有必要的。


AUTOSAR除了分層軟件架構體系，詳細模塊組件設計之外，另一重要的概念是提供了一整套應用程序開發的方法論。


該方法論從元模型開始，制定了每個環節需要的工作內容，輸出文件以及產出文件，中間的交互文件和格式也有具體的定義，例如arxml為載體的交互文件。對于系統建模工具，需要有專門的編輯工具，ECU的底層功能由配置工具去做相應的配置，進而生成相應的執行代碼。


所有的這些工作都是為了實現這些目標：為了應對數量日益增多且功能復雜的汽車ECU，同時要改善每家ECU控制器供應商各自開發軟件而造成的軟件質量參差不齊，并且難以有效開展合作的問題。


由于可以購買到第三方軟件公司提供的基礎軟件模塊，可以縮短產品研發時間，更快的推向市場。而可拓展的分層軟件架構可以提供靈活多變的解決方案，適應不同控制器的軟件要求。

AUTOSAR 方法論

AUTOSAR的方法論總體設計開發分為三個步驟，系統配置，ECU設計與配置，代碼生成。


首先由整車廠完成整個功能架構，系統架構，軟件架構，并且定義總線的拓撲結構，以及信號列表。軟件組件框架包含每個軟件組件之間的交互關系，運行實體等要素。之后將軟件組件按功能分配給ECU硬件。


在完成這些設計后，系統描述文件包含了每一個ECU軟件框架描述，并且包含了每個ECU的系統信號。這些描述文件將分發給ECU開發商去完成每個ECU具體底層功能配置并生成相應的BSW代碼，同時還需開發應用軟件的行為模型及代碼。


RTE是虛擬功能總線在具體ECU上的實現，它承擔著在ECU內運行的應用層軟件組件之間互相通信，以及應用軟件向通信協議棧發送總線信號的作用。

Classic AUTOSAR 軟件架構

這張圖就是大家都很熟悉的CP AUTOSAR的軟件架構。包含了微控制器抽象層，ECU抽象層，服務層，還有復雜驅動層，RTE將底層軟件和上層應用軟件組件分開，提供虛擬總線實時運行環境。


例如應用程序要向總線上發送一個總線信號，典型的處理過程是首先通過RTE把信號傳給COM通信模塊, 它屬于通信服務層。通信硬件抽象層的作用是將不同類型的網絡通信進行抽象，使得上層的處理不需要關心底下具體是以哪些類型的網絡發送數據。


通信驅動層的作用是使上層模塊可以更方便的使用硬件設備，比如用簡單的API去操作發送或接受一個CAN信號，具體對硬件的處理操作由驅動去完成。微控制器抽象層的作用就是解決不同微控制器廠商硬件設計的差異，使得驅動層可以統一標準化設計。

汽車軟件架構的發展趨勢

對于汽車軟件架構未來的發展趨勢，有以下幾個方面。
第一是面向服務的軟件架構變化，服務架構的轉型需要將當前基于信號的軟件設計進行重構，使得功能的調用更符合服務化的通信框架。


第二，中央計算+區域控制分布式遠程調用框架RPC。當前適用車內使用的RPC就是SOME/IP，它可以在運行CP AUTOSAR的實時控制器上使用，也可以在運行AP AUTOSAR的高性能SOC上使用，是兩個不同平臺進行通信的紐帶。


第三，高算力SoC軟件架構也是重要的發展方向，傳統功能上移到中央計算單元，計算集中化是未來的電子電氣架構趨勢。也對高算力SoC的軟件架構提出更高的要求。


同時這樣的軟件架構還涉及到一個新的概念，混合關鍵性軟件系統，即在一個SoC系統上同時運行不同安全等級的軟件系統，這對軟硬件隔離技術，虛擬化技術都是新的考驗。另外云端，車端，以及基礎設施的功能協同等也是發展的新趨勢。


對于前面講的未來的汽車軟件發展趨勢，當前比較推薦的方案就是AP AUTOSAR。設計AP AUTOSAR的初衷就是該平臺應具備一定的實時性，高可靠性，同時適合運行高性能軟件算法的應用場景。另外該平臺具備一點的靈活性，可以動態的加載車輛應用功能。





AP AUTOSAR的功能組件。其核心組件ARA COM提供了服務化的通信功能，自適應應用程序AA之間的通信通過ARA COM來完成。屬于Services類型的模塊包括升級和配置管理UCM，提供FOTA, SOTA的功能支持。


Security Management提供和信息安全相關的服務，Diagnostics則提供和診斷相關的功能入口。其他API組件，提供了時間管理，執行管理，Persistency，健康管理等，都是必須的平臺中間件軟件。


AP AUTOSAR的興起源于當前對高性能SoC系統的應用需求，在一個完整的汽車汽車電子電器架構中，因為每個ECU都有其特殊的應用需求，所以AP AUTOSAR, CP AUTOSAR, 以及非AUTOSAR的ECU將是同時存在的，都扮演者重要的角色。


在AP AUTOSAR發展的同時，CP AUTOSAR也在繼續升級新增新的模塊，以適應新的需求。


當然，除此之外，未來汽車電子軟件中人工智能技術也是一大應用。汽車電子也會跟其他行業會有更多的交集，也會引入其他行業的很多技術，如IEEE制定的相關標準；跟OPC UA結合以解決TSN的問題，機器領域的ROS，以及已經在航空航天中使用的到的光纖通信技術等。


汽車電子軟件未來發展如何，讓我們拭目以待吧！

本期分享就到這里，進群、工具鏈評估、培訓、集成等其他問題，也可以隨時與我們聯系。

聯系我們

微信：shactiontech
郵箱：support@shactiontech.com

總結

以上是生活随笔為你收集整理的搞一下新架构下的软件技术 | 12 汽车电子软件的过去与未来的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。