电子电气架构—-整车PNC简介（局部网络管理）

我是穿拖鞋的汉子，魔都中坚持长期主义的汽车电子工程师。

老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：

做到欲望极简，了解自己的真实欲望，不受外在潮流的影响，不盲从，不跟风。把自己的精力全部用在自己。一是去掉多余，凡事找规律，基础是诚信；二是系统思考、大胆设计、小心求证；三是“一张纸制度”，也就是无论多么复杂的工作内容，要在一张纸上描述清楚；四是要坚决反对虎头蛇尾，反对繁文缛节，反对老好人主义。

一直很喜欢发小老李QQ签名那句话—生活如逆水行舟，不进则退。农村做题家出来的汉子，我可能已经不具备享受快乐的权力，只有做个躬行的卒子，一步一个脚印往前走。

中年男人尽量避免陷入历史虚无主义，自己无需问“人活着为了什么？”，做自己该做之事，七八月只管播种，到了十一二月收获季节，自有收获。

一、为何整车需要PNC局部网络管理?

在某些场景下，我们希望关闭其他ECU，仅保留必要设备仍在工作状态，以降低蓄电池电量消耗。我们一般将这些在某种条件下需要保持同样工作状态，且连接在同一总线（或由网关连接）的ECU称之为一组PNC，也即partial network cluster，进行网络管理。

PNC上的这些ECU在逻辑意义上形成了一个网络，例如，实际物理网络中ABCD四个ECU当中，AB两个ECU为一组PNC，它们需要保持同步唤醒或睡眠，但是它们的睡眠和唤醒可以不影响C和D的网络状态。

如果网关使能了PNC，那么PNC的概念可以扩展到不同的总线上，在更大的网络里面形成一组PNC。没有了部分网络的功能，NM消息只能做到整条总线的唤醒与保持唤醒状态。

PNC（Partial Network Cluster，局部网络信号簇）作为 AUTOSAR 架构下局部网络管理的核心执行单元，主要从总线信号层面实现对整车网络的精细化管控，其存在是为解决传统整车网络管理的诸多痛点，适配现代汽车尤其是新能源汽车的功能与能耗需求，具体原因如下：

-> 1、极致优化能耗，适配新能源汽车核心需求

传统网络管理中，只要某一功能触发网络唤醒，同一网段甚至整车所有 ECU 都会被唤醒，大量无关 ECU 的无效运行会造成严重电能浪费。而 PNC 可将整车 ECU 按功能划分为多个虚拟局部网络簇，每个 PNC 能独立控制簇内 ECU 的唤醒与休眠。比如车辆处于充电场景时，仅充电相关 PNC 内的 ECU 工作，发动机管理、变速箱控制等无关 ECU 保持休眠；哨兵模式下也仅激活安防相关 PNC。这一操作大幅降低了整车静态功耗，对依赖电池续航的新能源汽车而言，能有效提升续航能力，延长电池使用寿命。

-> 2、减少网络冗余通信，提升总线运行效率

现代汽车的 ECU 数量不断增加，总线需传输的信号愈发繁杂。传统网络管理中，全网唤醒会伴随大量非必要报文传输，易造成总线拥堵，影响关键信号的传输时效性。PNC 通过精准控制通信范围，仅让功能相关的网络簇传输报文。例如调节座椅通风时，仅触发座椅控制相关 PNC 的信号交互，避免其他如动力系统、娱乐系统的总线信号干扰。这既减少了总线带宽占用，又降低了信号传输延迟，让车辆各类功能指令的响应更迅速，提升整车控制的流畅性。

-> 3、适配复杂功能场景，实现跨网段协同管理

汽车很多功能的实现需要不同网段的 ECU 协同工作，如座椅通风加热功能，相关 ECU 可能分布在不同 CAN 网段。PNC 作为 AUTOSAR COM 层的信号簇，可突破网段限制，通过总线信号层面的控制，将不同网段中功能关联的 ECU 纳入同一 PNC 管理。当该功能被触发时，PNC 能同步唤醒跨网段的关联 ECU 并协调其通信，保障功能稳定运行。同时面对露营模式、远程座舱控制等多样化的特殊场景，可灵活配置专属 PNC，无需重构整车网络架构，就能满足不同功能场景的网络管理需求。

-> 4、降低系统开发与维护成本，增强拓展性

在整车开发阶段，PNC 可按功能模块化划分网络，开发人员能针对不同 PNC 并行开展相关 ECU 的调试与开发工作，无需等待整体网络调试，缩短开发周期。而且后续车型迭代时，若新增如自动驾驶辅助相关功能，只需新增对应的 PNC 并配置关联 ECU，无需对原有网络结构做大改。此外，故障排查时，因 PNC 划分了明确的功能网络簇，可快速定位故障所在的 PNC 范围，缩小排查对象，降低维修难度和成本。

二、PNC是如何实现对整车网络的精细化管控的？

PNC 作为 AUTOSAR COM 层的局部网络信号簇，主要依靠功能分组划分、专属报文控制、状态机调度，再配合与 AUTOSAR 架构中多模块的协同，从总线信号层面实现对整车网络的精细化管控：

-> 1、按功能逻辑划分 PNC 簇，锁定管控范围

PNC 会先将整车中功能关联的 ECU，跨网段整合为多个虚拟局部网络簇，每个簇对应特定车辆功能，以此明确管控边界。比如把空调控制单元（HVAC）、远程信息处理控制单元（TCU）等归为 “远程空调控制” PNC 簇，把充电相关 ECU 归为 “充电” PNC 簇。这种划分打破了传统网段的限制，哪怕 ECU 分布在 CAN、LIN 等不同通信通道，只要功能相关就能纳入同一 PNC 管控，为后续精准唤醒和休眠打下基础，避免管控范围过大导致无效能耗。

-> 2、通过专属 PNC NM 报文，精准传递管控指令

PNC 的管控指令依靠专属的 PNC NM 报文传递，这类报文的用户数据段中包含 PNC 比特向量（Bit Vector），可看作一组 “功能开关”，每一位对应一个 PNC 簇的状态。同时 NM 报文中的局部网络信息位（PNI）是总开关，只有该位置 1 时，PNC 的管控才生效。当某功能需要启动时，触发的 ECU 会发送 PNC NM 报文，并将对应 PNC 簇的比特位置 1；功能结束后，再将该比特位置 0。其他 ECU 只需监听报文，就能判断自身是否需要响应，比如远程开空调时，仅对应 PNC 簇的 ECU 会识别到比特位指令并唤醒。

-> 3、状态机调度 + 超时机制，管控网络启停与休眠

PNC 依托标准状态机实现状态的有序切换，以此管控网络的激活与休眠。其核心状态包括休眠、唤醒消息重复发送、活跃、准备休眠四种。比如功能触发时，PNC 从休眠状态切换到唤醒消息重复发送状态，确保所有相关 ECU 都能接收唤醒指令，随后进入活跃状态保障功能通信；功能执行中，相关 ECU 会周期性发送 PNC NM 报文，维持网络活跃。当功能结束，报文比特位置 0 后，PNC 进入准备休眠状态，若经过预设超时时间，确认无其他激活请求，就会切换到休眠状态，避免网络无效运行。

-> 4、联动多模块协同，保障跨场景管控稳定性

PNC 并非独立工作，而是与 AUTOSAR 架构中的多个核心模块交互，实现复杂场景下的精准管控：

A：通信管理模块（ComM）：负责记录各类通信请求，判断是否激活对应的 PNC。当该 PNC 下所有通信通道都就绪时，会标记就绪标志，确保管控指令能正常执行。

B：网络管理模块（Nm）：主导 PNC 状态机的切换，根据功能需求发送唤醒报文或释放网络资源，是状态管控的核心协调者。

C：协议数据单元路由模块（PduR）：承担 PNC NM 报文的路由转发任务，能将报文精准传递到不同通信通道，保障跨网段 PNC 簇的 ECU 都能接收指令，比如协调车身控制模块与空调控制模块的跨网段通信。

-> 5、遵循映射规则，避免管控冲突

PNC 有明确的功能与簇映射规则，以此保障管控逻辑不混乱。规则规定多个虚拟功能组（VFC）可对应同一个 PNC 簇，实现功能聚合管控；但不允许一个虚拟功能组对应多个 PNC 簇。比如座椅加热和座椅通风两个功能组，可共用一个 PNC 簇管控；而充电功能组不能同时由两个 PNC 簇管控，防止出现一个簇发唤醒指令、另一个簇发休眠指令的冲突情况，保障管控指令的唯一性和有效性。

无论是开启还是关闭ECU的通信功能，都是需要进行请求的，而这个请求则分为内部请求与外部请求，我们称之为External Internal Request Array，也即EIRA。每一个ECU都需要有EIRA，来根据部分网络活动进而切换IPdu Group的状态。

至于ERA，External Requested Array，它主要用于网关，仅收集外部PN请求的场景。网关会将外部PN请求镜像回请求总线，同时将这个请求发送到其他的总线上。

IRA，Internal Requested Array，代表ECU内部对于PNC状态的请求，既可以是SWC通过RTE直接请求ComM接口，或者在某种条件满足时，由BswM请求ComM接口。

搁笔分享完毕！

愿你我相信时间的力量

做一个长期主义者