背景介绍
提起“匮电”二字，做测试的老司机定会虎躯一震，而根据过往经验，“网络管理”常是引起匮电的“钉子户”，所以针对网络管理的验证是测试的重中之重。
国内网络管理应用已从早期OSEK NM过渡到AUTOSAR NM，部分OEM使用了AUTOSAR NM的PN特性，本文从NM概念用途、PN的实现方式、CANoe下实现PN网络管理测试思路几个方面展开介绍。
什么是网络管理
汽车上的ECU在工作的时候需要通过网络来与其它ECU进行数据交换，而在不工作的时候需要进入低功耗状态来尽可能减少电量消耗。比如：
当拉动门把手准备使用车辆时，需某ECU接收到这个信息后在短时间能够从低功耗状态进入工作状态，并且快速地唤醒其它ECU，然后经过诸如用户认证等功能来使车辆能够被正常使用
当锁车离开后，相关ECU也需要判断这个信息，然后决定车辆需要进入非工作状态，网络通信需要被关闭且ECU需要进入低功耗状态
上述的工作循环可以概括为：
图1 工作循环示例
而这样的网络行为正是通过网络管理来实现的。
什么是PN网络管理
PN （Partial Network）即“局部网络”，通过一些规则（通常按照功能类）将车辆网络进一步划分为不同的“局域网”（类同于GM Global A架构中Virtual Network），通过PN网络管理处理其各种状态。
为什么需要PN
传统网络管理采用的是简单明了的“同醒同睡”的方式，但在一些场景中，我们只需要网段中有限的ECU参与工作，而不是全部的ECU，这造成了多余的电量消耗。
在ECU数量较少时还可以接受，但随着ECU的数量的增加，这个“浪费”问题就显得更为突出（当然，也可以通过设计不同的电源回路/模式控制ECU的供电等方案，但难以达到理想状态且会增加其它问题）。
PN正是通过对于网络的再次细分，在不同的场景下使不同的ECU处于工作状态，而无关的ECU仍处于低功耗状态，以达到进一步减少电量消耗的目的。
图2 PN网络示例
NM PDU
ECU请求网络以及接收到其它ECU的网络请求是通过NM PDU （Network Management Protocol Data Unit）来实现的。
以CAN网络为例，简单来说，当ECU需要请求网络时需要发送NM PDU；不需要请求网络时停止发送NM PDU。其它ECU在接收到NM PDU时，认为网络被请求。PN信息的接收发送也是类似，只是它是通过信号的形式在NM PDU中更新。
在AUTOSAR中，通常使用8个字节的数据分配给NM PDU，包含Source Node ID，CBV （Control Bit Vector）和User Data，其中User Data为用户自定义的内容，使用PN的情况下将全部或者部分User Data用于定义一组PN。
图3 NM PDU格式
CBV包含了NM模块的一些控制信息，使用PN时需要使用Partial Network Information Bit。
图4 CBV内容
除了上述的用于CAN/CAN FD的NM PDU外，PN网络管理还可以支持FlexRay。在FlexRay的NM PDU中，需要分为NM-Vote PDU和NM-Data PDU。CAN和FlexRay来说NM PDU有一些差异，但是其对于PN信息的处理是一样的。
状态机
ECU通过接收和发送NM PDU来传递网络管理的信息，而这些信息也决定ECU所处的状态。
以CAN通信为例，NM模块包含NM的状态机，针对ECU的通信端口，表示端口所处的网络管理状态，简单来说为网络的请求和释放。
图5 NM状态机
而对于PN网络来说，还包含PN的状态机，针对ECU所关联的PN，表示PN的状态，简单来说为PN的请求和释放。
图6 PNC状态机
而上述两者需要反馈到通信的状态上，因此还存在通信的状态机，针对ECU的通信端口，表示通信的状态，简单来说为通信的开启和关闭。
图7 ComM channel状态机
这些状态机需要共同作用，使ECU能正常的休眠和唤醒。当然，这个过程还关联有其它的状态机，在此就不赘述，有兴趣的可以参考AUTOSAR的规范。
PN网络管理测试方案
通过上述的内容，可以看到，其实PN网络管理只是在传统网络管理的基础上将PN信息添加在NM PDU中供ECU识别（当然这个说法忽略了大量细节，但就测试方案来说还可以接受）。如果被测ECU只包含1个通信端口（如1个CAN端口），我们采用的测试思路可以是：
图8 测试方案1
然而，当ECU的复杂性增加时，这种判断的方法就变得比较困难。比如某个ECU包含2个通信端口，触发某个事件后，其网络行为可能为：
图9 网络行为示例
这个情况在使用PN时更加常见，尤其是当这个ECU作为中央网关或将来的域控制器，需要将PN从一个网段路由到另一个网段。当然，对于单个部件的环境来说，这种行为还处于可控、有序的状态，如果放在系统级、实车环境中，先前的测试思路就会变得“一团乱麻”。
图10 网络行为示例2
因此必须要有新的思路和方法，北汇在长期工程实践中积累了特有的方案，借助于Vector公司的CANoe所提供灵活而强大的函数库，实现了对上述问题的“解耦”，从而解决这个“老大难”。如下为使用新方法，在CANoe环境下开发测试工程并自动生成的针对部件和系统级的测试报告。
图11 CANoe自动生成节点级PN测试报告示例
图12 CANoe自动化生成PN系统级测试报告示例
总结
网络管理是车载网络中非常重要也是比较复杂的内容，一方面它与功能有强相关性，不同的功能需求就可以有不同的网络行为，从而影响网络管理的状态；另一方面，网络管理本身强调逻辑，需提供足够的信息，实现与硬件接口间的交互；更困难的点在于网络管理涉及时序的控制，这就不可避免地与ECU的各种中断程序、各种随机事件耦合，会出现很多疑难杂症。
尤其是在系统层面，常会出现类似：A影响B，B影响C，C影响A，小问题累积成大问题，产生各种异常行为的情况。这也对测试规范的开发提出了更高的要求，即要验证逻辑又要覆盖场景。
随着以太网将成为主干网，随之SoA及网络动态配置应用，网络管理也将会迎来新的变化和调整。
仅以此篇文章投石问路，共同面对新的挑战。做好当下，即（不）是（畏）未来！
注：文中部分图片来源于AUTOSAR
参考文献[1] AUTOSAR_SWS_CANNetworkManagement
[2] AUTOSAR_SWS_FlexRayNetworkManagement
[3] AUTOSAR_SWS_COMManager
/3 
