隨著整車功能的不斷演進，車上各類用電設備（控制器、執行機構、感知設備等）的用電功耗越來越大，為了降低整車能耗，國內外很多OEM及Tire1都在考慮相關的機制及方案，其中PN局部網絡管理機制，以其簡單、靈活的特點獲得眾多落地應用。

基于AUTOSAR方案的局部網絡管理機制，通常簡稱為AUTOSAR PN（Partial Network），局部網絡管理本質上是要實現只讓需要支撐功能實現的控制器工作，其他控制器保持在低功耗狀態。AUTOSAR PN是通過NM報文（NMPDU）的方式來達到此目標，NMPDU的典型格式如下表所示。

PN開發流程

當前OEM的車型平臺大多為迭代開發，依托現有平臺增加PN通常是較快速的方案。所以相較于復雜、全面的AUTOSAR正向PN開發方法論，OEM更多采用逆向的開發方式。逆向的PN開發流程通過分析當前現狀來完成PN的開發，選取整車改動較小的方案推進，整體方案具備輕量化的優勢，開發周期短，過程交互簡單。

本文重點介紹下逆向開發的關鍵步驟：

• 第一步：PN場景設計及梳理

結合整車的功能列表、用車人典型的用車場景及OEM考慮的其他場景，確定車型需開發的場景范圍，比如全部喚醒、防盜、遠控、充電等。場景開發應考慮場景觸發的頻率、給用車客戶帶來的收益以及OEM本身的收益。

• 第二步：PN開發基礎原則確定

結合當前量產車型的EE架構，確定一個基礎的PN開發規則，比如開發全局PN還是部分PN以及基礎的功能鏈路，形成本次開發的基礎原則文件，輸出到后續步驟。

• 第三步：PN場景功能鏈路梳理及分析

根據確定的功能場景及PN開發基礎原則及整車所有的子系統功能規范輸入，梳理場景觸發后的完整功能鏈路，這其中要切實考慮鏈路中涉及到的ECU、關鍵信號值的變化、功能執行前提條件、存儲值/實時值需求、以太網接口調用需求、供電需求、網段需求等關鍵信息，通過細致的方案設計來避免場景上的鏈路缺失和場景間的關聯；另外還需要考慮休眠釋放條件，防止場景的休眠異常。

• 第四步：網絡線的所有工作

在功能線開發的同時，網絡線可同步開發相關的PN需求規范及休眠喚醒策略；在制定好PN場景后，可以開始NMPDU的制定、車型網絡相關方案的制定；PN的通信設計和診斷設計應結合PN開發的基礎原則及網絡需求規范開展，比如通信設計是否要考慮應用報文與場景的關聯、診斷設計是否要考慮全工況下的DTC記錄等。

• 第五步：功能及網絡的測試驗證

結合上述開發的輸入，開展測試工作以驗證符合性。

以上的每個步驟都需要形成相關的輸入輸出來保證整個方案體系的一致性，如相關模板、PN開發基礎原則、場景功能鏈路方案、控制器PN方案、網絡需求規范、休眠喚醒條件、測試規范/用例、測試腳本等等。此外，控制器的實現如基于AUTOSAR CP協議棧，需要同步考慮功能需求與BSW的Mapping關系，保證功能需求的落地可行性。

下圖即為同一個網段下不同控制器的喚醒示意。當某PN場景觸發后，控制器置位相關的PN信息，其他控制器根據置位的PN信息來決定是否與自身相關，如相關則喚醒以支撐功能實現，如不相關則維持在低功耗狀態。

注：本文集中在CAN總線的局部網絡管理。

• 硬件支持

實現PN的控制器應結合實際方案決定是否需要在硬件層面支持報文過濾功能，常見的支持硬件過濾功能的CAN收發器為NXP TJA1145，其在硬件層面設計了符合ISO 11898-2中Selective Wake-up的特性，可過濾自身關心的報文。通過使用此類收發器，可以達成控制器的功耗控制，否則無法實現功耗上的按需控制。

• 軟件支持

PN功能的實現，使用AUTOSAR CP協議棧是非常方便的，與常規的NM相比，PN軟件模塊主要集中在BSW的ComM和CanNM中，ComM負責PNC狀態機的監控及跳轉，CanNM配合ComM負責NMPDU和CAN通道的維持和釋放，基于AUTOSAR軟件配置工具可以快速切換為支持PN。如使用手寫代碼，鑒于PN狀態機的規則相對簡單易懂，也可以方便的實現此類功能。

經緯恒潤依托自身豐富的技術積淀，結合架構開發、總線開發、嵌入式開發等綜合經驗，對整車功能進行分析與梳理，形成了一套邏輯嚴密、場景適應性強的從場景-功能-控制器-自動化測試系統的綜合解決方案框架。該方案包含了對市場需求的深刻理解，已應用于多家OEM的實際車型開發中。

基于此綜合解決方案，針對OEM不同車型的獨特性、現有功能配置及軟硬件實際情況，細心規劃并執行定制化實施方案，贏得了合作伙伴的廣泛信賴與深度認可。