聊聊AUTOSAR PN网络管理测试开发实践

背景介绍

提起“匮电”二字，做测试的老司机定会虎躯一震，而根据过往经验，“网络管理”常是引起匮电的“钉子户”，所以针对网络管理的验证是测试的重中之重。

国内网络管理应用已从早期OSEK NM过渡到AUTOSAR NM，部分OEM使用了AUTOSAR NM的PN特性，本文从NM概念用途、PN的实现方式、CANoe下实现PN网络管理测试思路几个方面展开介绍。

什么是网络管理

汽车上的ECU在工作的时候需要通过网络来与其它ECU进行数据交换，而在不工作的时候需要进入低功耗状态来尽可能减少电量消耗。比如：

• 当拉动门把手准备使用车辆时，需某ECU接收到这个信息后在短时间能够从低功耗状态进入工作状态，并且快速地唤醒其它ECU，然后经过诸如用户认证等功能来使车辆能够被正常使用
• 当锁车离开后，相关ECU也需要判断这个信息，然后决定车辆需要进入非工作状态，网络通信需要被关闭且ECU需要进入低功耗状态

上述的工作循环可以概括为：

而这样的网络行为正是通过网络管理来实现的。

什么是PN网络管理

PN （Partial Network）即“局部网络”，通过一些规则（通常按照功能类）将车辆网络进一步划分为不同的“局域网”（类同于GM Global A架构中Virtual Network），通过PN网络管理处理其各种状态。

为什么需要PN

传统网络管理采用的是简单明了的“同醒同睡”的方式，但在一些场景中，我们只需要网段中有限的ECU参与工作，而不是全部的ECU，这造成了多余的电量消耗。

在ECU数量较少时还可以接受，但随着ECU的数量的增加，这个“浪费”问题就显得更为突出（当然，也可以通过设计不同的电源回路/模式控制ECU的供电等方案，但难以达到理想状态且会增加其它问题）。

PN正是通过对于网络的再次细分，在不同的场景下使不同的ECU处于工作状态，而无关的ECU仍处于低功耗状态，以达到进一步减少电量消耗的目的。

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。

CBV包含了NM模块的一些控制信息，使用PN时需要使用Partial Network Information Bit。

除了上述的用于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的通信端口，表示端口所处的网络管理状态，简单来说为网络的请求和释放。

而对于PN网络来说，还包含PN的状态机，针对ECU所关联的PN，表示PN的状态，简单来说为PN的请求和释放。

而上述两者需要反馈到通信的状态上，因此还存在通信的状态机，针对ECU的通信端口，表示通信的状态，简单来说为通信的开启和关闭。

这些状态机需要共同作用，使ECU能正常的休眠和唤醒。当然，这个过程还关联有其它的状态机，在此就不赘述，有兴趣的可以参考AUTOSAR的规范。

PN网络管理测试方案

通过上述的内容，可以看到，其实PN网络管理只是在传统网络管理的基础上将PN信息添加在NM PDU中供ECU识别（当然这个说法忽略了大量细节，但就测试方案来说还可以接受）。如果被测ECU只包含1个通信端口（如1个CAN端口），我们采用的测试思路可以是：

然而，当ECU的复杂性增加时，这种判断的方法就变得比较困难。比如某个ECU包含2个通信端口，触发某个事件后，其网络行为可能为：

这个情况在使用PN时更加常见，尤其是当这个ECU作为中央网关或将来的域控制器，需要将PN从一个网段路由到另一个网段。当然，对于单个部件的环境来说，这种行为还处于可控、有序的状态，如果放在系统级、实车环境中，先前的测试思路就会变得“一团乱麻”。

因此必须要有新的思路和方法，北汇在长期工程实践中积累了特有的方案，借助于Vector公司的CANoe所提供灵活而强大的函数库，实现了对上述问题的“解耦”，从而解决这个“老大难”。如下为使用新方法，在CANoe环境下开发测试工程并自动生成的针对部件和系统级的测试报告。

总结

网络管理是车载网络中非常重要也是比较复杂的内容，一方面它与功能有强相关性，不同的功能需求就可以有不同的网络行为，从而影响网络管理的状态；另一方面，网络管理本身强调逻辑，需提供足够的信息，实现与硬件接口间的交互；更困难的点在于网络管理涉及时序的控制，这就不可避免地与ECU的各种中断程序、各种随机事件耦合，会出现很多疑难杂症。

尤其是在系统层面，常会出现类似：A影响B，B影响C，C影响A，小问题累积成大问题，产生各种异常行为的情况。这也对测试规范的开发提出了更高的要求，即要验证逻辑又要覆盖场景。

随着以太网将成为主干网，随之SoA及网络动态配置应用，网络管理也将会迎来新的变化和调整。

仅以此篇文章投石问路，共同面对新的挑战。做好当下，即（不）是（畏）未来！

注：文中部分图片来源于AUTOSAR