局部網絡在AUTOSAR架構中的應用及優化

皇甫仁杰（泛亞汽車技術中心，上海　201201）

局部網絡在AUTOSAR架構中的應用及優化

皇甫仁杰
（泛亞汽車技術中心，上海201201）

通過對局部網絡的研究，提出了一種基于AUTOSAR實現局部網絡的設計方法。通過對軟件架構及策略的優化，使PN及AUTOSAR能更好地應用在整車網絡場景中。

AUTOSAR；軟件架構；局部網絡

近幾年來，汽車的節能減排問題備受關注，大部分OEM廠商紛紛在各個領域進行設計優化，其中網絡管理的設計優化 （采用局部網絡）就是一個有效的措施。因為，市場上大部分車輛在點火開關打到OFF擋之后，仍有一部分功能需要使用，例如：車輛防盜、電子駐車功能等。但是現如今普遍的設計方法是整個網絡采用同睡同醒，所以導致整車OFF之后，很多沒必要繼續工作的模塊依舊被喚醒著。為了降低電量消耗，避免蓄電池電量消耗過多導致汽車無法起動，整車網絡采用局部網絡，即進入OFF后，大部分不需要工作的模塊進入低功耗模式。

比如IGN OFF后，并且幾秒之后整車網絡都處于休眠，這個時候按下電子制動，儀表上需要顯示，就需要電子制動模塊喚醒IPC，基于同睡同醒的網絡架構就會喚醒整個網段，造成浪費。假如EPB開關是接在一些架構類電子模塊，需要進行跨網段喚醒的話，就會喚醒2個網段，造成更多電能損耗。所以針對這個問題，AUTOSAR及各大主機廠都已經開始制定新的網絡管理方案-局部網絡 （Partial Network，簡稱PN）管理，以實現分組睡眠和喚醒。

1AUTOSAR架構介紹

AUTOSAR是AUTomotive Open System Architecture（汽車開放系統架構）的簡稱，是AUTOSAR組織為汽車工業開發的一個開放的、標準化的軟件架構標準。

AUTOSAR主要的標準分為3部分：①獨立于硬件的分層軟件架構；②標準的系統設計及開發流程 （包括開發流程的標準化及工具鏈的標準化）；③標準化的應用接口。

本文涉及的開發主要是基于AUTOSAR的分層軟件架構，如圖1所示。

圖1　AUTOSAR軟件架構示例［1］

AUTOSAR分層軟件架構即是實現基礎軟件與應用軟件的分離，使基礎軟件與APP都能相對獨立，可移植性好，模塊化降低成本。

這其中被標準化的基礎軟件主要為4個層次：服務層 （Services Layer）、ECU抽象層 （ECU Abstraction Layer）、微控制器抽象層 （Microcontroller AbstractionLayer）和RTE（Runtime Environment）。

2　局部網絡概念

局部網絡 （Partial Network）顧名思義是將整車網絡分割成幾個小的局部網絡，類似于因特網與局域網的關系，但是需要注意的是整車局部網絡的分割是基于不同的feature點的，一個模塊可以從屬于多個局部網絡。

PN組劃分示例見圖2。門鎖功能相關的模塊分為一個PN組；車輛OFF下IPC顯示相關功能分為一個PN組。

圖2　PN組劃分示例

3　整車網絡架構設計

3.1整車網絡架構

基于整車電氣架構，假如分了多路CAN，則需要實現局部網絡的網段基于AUTOSAR實現 （一般車身CAN較容易實現，動力或者底盤CAN基于成熟性考慮，切換到AUTOSAR的進程較慢）。網絡架構圖示例見圖3。

圖3　　網絡架構圖示例

車身舒適性CAN是AUTOSAR CAN，而PT CAN和CH CAN是傳統的同睡同醒的主從式網絡。

3.2局部網絡劃分

局部網絡一般只在整車電源模式為OFF時實現，在其它電源模式下，AUTOSAR子網的節點將進入強制喚醒狀態，當檢測到電源模式切換到OFF模式后，節點再進入局部網絡狀態。ECU請求PN喚醒、睡眠都必須通過網絡管理報文來實現。

并且，根據功能點劃分局部網絡越細，需要喚醒的模塊就越精確，不需要被喚醒的模塊就會越少，降低能耗就越可觀。但是，PN組劃分過多，會導致整車功能繁雜性提升，這里就需要設計人員掌握比較好的一個平衡點。PN分組示例見表1。

表1PN分組示例

從表1中看出，整個網絡在電源非OFF下需要同時喚醒，所以所有ECU都劃分為PN1，從PN2開始根據功能劃分，某個功能需要幾個模塊被喚醒，就劃分哪幾個為一組。

3.3支持局部網絡的軟硬件要求［2］

局部網絡需要CAN transceiver帶濾波功能，并且底層協議棧 （通常采用vector的Autosar協議棧）支持PN。

硬件可以采用NXP的收發器TJA1145，除了傳統收發器的TX、RX引腳，該收發器可通過SPI與CAN控制器相連。通過SPI，MCU可控制CAN收發器的模式轉換以及設置收發器的報文濾波，實現特定報文喚醒的功能。硬件連接示意見圖4。

圖4　　硬件連接示意圖

同時收發器需要設置相應掩碼：①報文地址場（Frame ID），值為XXX-XXX；②報文數據場字節長度 （DLC），值為XX；③報文數據場 （AUTOSAR已定義默認格式）。

設計人員可以根據PN分組情況在user data自定義控制每個PN組的位。這樣就實現了特定的網絡管理報文才能喚醒相應的一個分組內的模塊。

4　子節點系統設計優化

在整車網絡架構設計完成后，子節點也完成相應的硬件選型。接下來的設計就是如何更好地設計各模塊的上層軟件與底層軟件間的軟件架構，使其更適應于復雜的應用場景。

4.1系統方案設計

局部網絡是將一個網段分成了多個PN組，單獨一個PN組又等同于一個獨立的網絡，各個PN之間會有復雜的仲裁管理，在軟件上單獨為其做一個獨立的模塊用于管理網絡。

4.2軟件實現

針對于每個功能點進行編號，用于軟件區分不同的APP請求，如圖5中的APP_Function ID，通過RTE將Request發送至PN_Manager，在做好仲裁管理后再調用底層協議棧請求網絡。

圖5　　軟件架構示意圖

針對復雜的應用場景，可以將APP的網絡請求分成以下2種。

1）事件性的PN請求APP_FunctionID請求事件性的PN，該事件性請求發生之后，如果APP_FunctionID不再有新的事件性申請，則PN_Manager自動等待一段時間后自動釋放該網段的PN。

2）永久性的PN請求APP_FunctionID如果向PN_Manager申請永久性的PN請求接口，那么意味著APP_FunctionID必須配對有一個釋放接口，如果APP_FunctionID不申請釋放接口的話，那么該PN會一直被設置為激活狀態。而一旦APP_FunctionID被釋放之后，PN_Manager將立即釋放PN而不做任何超時等待。所以永久性的PN接口意味著一旦被請求，PN將永久性激活。

基于上述2種方式，就能較好地適用于復雜的應用場景。然后做好軟件的時序設計，就可以實現不同PN分組休眠和喚醒，并達到比較好的系統強壯性。

5　模擬驗證

在前期開發階段我們使用CANoe進行模擬仿真，如圖6所示。

圖6　CANoe模擬仿真

前期簡單的邏輯都可以通過CANoe內置的編程工具來實現，以達到快速仿真的目的，并且通過圖3制作簡單的面板觀察總線情況。

開發后期，可以直接用真實節點構建網絡環境來測試，如圖7所示，設備：SPY3、bench、BCM、GW。

圖7　　臺架測試驗證

雙跳開關喚醒BCM時的一個應用場景：在網絡管理報文發出后，BCM喚醒了網關 （需GW轉發至ONSTAR），BCM發送定義好的621網絡管理報文，喚醒相應的PN組，網關節點回復定義好的627報文 （空的數據幀）。

6　總結

本文通過對整車網絡應用設計以及子節點軟硬件設計方法的介紹，提供了一種能較好地實現局部網絡的方案。鑒于節能減排的壓力，能夠廣泛適用于汽車網絡的開發，提供一種 “智能喚醒”的解決方案。該設計方法已經運用在2015款全新英朗車型上。

［1］heinecke H.automotive open system architecture-andustrywide intiative to manage the complexity of emerging automotive E/Earchitecture［J］.SAE paper 2004-21-0042.

［2］AUTOSAR官方網站.http：//www.autosar.org［OL］.

（編輯心翔）

Application of Localized Network in AUTOSAR Architecture and Its Optimization

HUANGFU Ren-jie
（Pan Asia Technical Automotive Center，Shanghai 201201，China）

A design method to realize localized network based on AUTOSAR is proposed here.The PN and AUTOSAR can be applied better in whole vehicle network through the optimization of software architecture and strategy.

AUTOSAR；software architecture；localized network

U463.6

A

1003-8639（2016）02-0052-03

2015-11-13；

2015-11-27