隨著整車功能的不斷演進，車上各類用電裝置（控制器、執行機構、感知裝置等）的用電功耗越來越大，為了降低整車能耗，國內外很多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不同車型的獨特性、現有功能配置及軟硬體實際情況，細心規劃並執行定製化實施方案，贏得了合作伙伴的廣泛信賴與深度認可。
瞭解更多
請致電 010-64840808轉6116或發郵件至market_dept@hirain.com（聯絡時請說明來自部落格園）