随着整车功能的不断演进，车上各类用电设备（控制器、执行机构、感知设备等）的用电功耗越来越大，为了降低整车能耗，国内外很多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不同车型的独特性、现有功能配置及软硬件实际情况，细心规划并执行定制化实施方案，赢得了合作伙伴的广泛信赖与深度认可。