【摘 要】智能驾驶的整车控制部分需要采用AUTOSAR框架进行开发，以满足高实时性以及高级别的功能安全需求。在本文中，通过采用AUTOSAR框架中网络管理的实现方式，对网络管理报文的格式进行定义，并描述CAN网络休眠与唤醒的状态转换、网络唤醒状态中各个子状态的切换、CAN Bus-off状态下的处理策略以及非正常电压模式下的处理策略等。在CANoe上对网络管理功能的策略进行验证，测试结果表明能够实现AUTOSAR网络管理的各项功能。
1 引言
近些年来，智能驾驶相关技术在世界范围内获得广泛关注和蓬勃发展。智能网联汽车是指搭载各传感器、控制器、执行器等装置，融合现代通信与网络、人工智能等技术，实现车与X（车、路、人、云等）智能信息交换、共享，具备复杂环境感知、智能决策、协同控制等功能，可实现 “安全、高效、舒适、节能”行驶，并最终可实现替代人来操作的新一代汽车[1-2]。美国高速公路管理局（NHTSA）发布了对自动驾驶各个级别的定义：Level 0代表人工驾驶，Level 1代表辅助驾驶，Level 2代表部分自动驾驶，Level 3代表条件自动驾驶，Level 4代表完全的自动驾驶。对于高级别自动驾驶，对控制器硬件以及基础软件的要求相对要高。高度自动驾驶级别的域控制器系统架构如图1所示。
图1 自动驾驶域控制器系统架构
数据融合与处理部分既要求实时性和一定的功能安全级别，又要求基础软件能管理更大内存，需要有文件系统的支持，因此采用具有文件系统的实时操作系统框架进行开发。整车控制部分需要基础软件具有高实时性以及高级别的功能安全需求，因此采用车控基础软件AUTOSAR框架进行开发[3]。AUTOSAR是由各大汽车制造厂商、零部件供应商、汽车电子、半导体和软件系统公司于2003年联合推出的一个开放的、标准化的软件架构。该架构专门应用于汽车电子领域，尝试通过增加软件模块的重用和互换，来降低系统软件架构的复杂度，从而优化整个软件的开发流程。满足AUTOSAR框架的基础软件，具有可移植、可扩展、高实时、高可靠、满足功能安全要求等特点[4]。本文采用基于AUTOSAR架构的网络管理，在汽车CAN系统中进行实现，并在CANoe上对网络管理的各功能进行仿真验证[5]。
2 AUTOSAR CAN网络管理报文格式
在网络管理中，网络中的各个节点通过网络管理报文进行通信，AUTOSAR CAN网络管理报文的数据场格式见表1。
表1 网络管理报文的数据场格式
表1中，字节0为ECU Address，作为源节点标识符，用以告知其他节点该报文是由哪个节点发送的；处于CAN网络中的每个节点都会分配一个唯一的标识符，本文中网络管理报文的ECU Address=0x439。字节1为控制比特向量，字节2～7为用户自定义的数据信息。本文中字节2User date 0用于将网络唤醒原因显示出来，其他自定义数据作为扩展保留，用“0x00”填充。表2列出了控制比特向量各位的含义。其中Bit0为重复报文状态请求位，置1代表需进入重复报文发送状态，清零代表不再需要重复报文发送状态；Bit4位为激活唤醒位，置1代表主动唤醒状态，清零代表被动唤醒状态。其他位为保留位，以0填充。
表2 控制比特向量格式
AUTOSAR网络管理包含3个主要状态：总线休眠状态、预休眠状态和唤醒状态。当网络节点满足休眠条件，不需要进行CAN通信时，进入总线休眠状态。网络处于总线休眠状态可以降低车辆电量消耗。一般情况下，当节点上电之后默认进入总线休眠状态，当在总线休眠状态接收到应用程序唤醒需求或者网络通信需求时，节点从总线休眠状态进入唤醒状态。当在唤醒状态下再次满足休眠条件时，节点首先进入预休眠状态，从预休眠状态延时一段时间再进入总线休眠状态。在预休眠状态下，节点停止网络管理报文和应用报文的发送，但是可以进行ACK的应答活动，用以监控总线网络需求。当定时器到时进入总线休眠状态后，关闭总线活动。3个主要网络状态的转移过程如图2所示。
图2 网络休眠与唤醒状态处理策略
当总线处于网络唤醒状态时，包含3个子状态：重复报文状态、正常模式状态和休眠准备状态。而重复报文状态又包含报文快速发送状态和正常发送状态两种。如上文提到，当在总线休眠状态接收到应用程序唤醒需求或者网络通信需求时，节点从总线休眠状态进入唤醒状态。当接收到应用程序唤醒需求时，节点进入重复报文状态中的报文快速发送状态，当接收到网络通信需求时，节点进入重复报文状态中的报文正常发送状态。当节点进入报文快速发送状态时，会开启定时器，当定时器到时后，节点从报文快速发送状态进入报文正常发送状态。节点进入重复报文状态后会开启另一定时器，定时器到时后，节点从重复报文状态退出。当网络需要继续进行CAN通信，节点从重复报文状态进入正常模式状态。当网络不再需要进行CAN通信，节点从重复报文状态进入休眠准备状态。在正常模式状态下，若需要与网络上的其他节点继续通信时，需要保持在正常模式，若不再需要网络通信，节点从正常模式状态进入休眠准备状态。进入休眠准备状态后需要停止网络管理报文和应用报文的发送。网络唤醒状态的转移过程如图3所示。
图3 网络唤醒状态处理策略
CAN网络管理需要考虑Bus-off状态下的处理策略。当检测到总线处于Bus-off状态时，停止网络报文和应用报文的发送，并开启定时器BusOffRecoveryCounter。定时器大小由Bus-off具体的快慢恢复策略决定。当定时器到时后，网络进入唤醒状态。若Bus-off状态进入之前网络已经处于唤醒状态，则退出Bus-off状态后，具体进入唤醒状态的哪个子状态由之前的历史状态确定。
网络管理需要在正常电压模式下进行工作。当总线处于总线休眠状态或者预休眠状态时，检测到应用程序的唤醒需求或者网络通信需求时，需要确认当前电压处于正常电压状态才会退出当前状态，进入网络唤醒状态。当总线处于网络唤醒状态时，检测到电压处于过低或过高电压状态，则退出网络唤醒状态进入预休眠状态。
在上述策略中详细描述了网络管理的状态转移过程，本文通过Stateflow的状态机进行实现，程序中的具体策略如图4所示。
图4 AUTOSAR网络管理处理策略
图5 本地唤醒策略测试结果
接收到网络通信需求时的测试结果如图6所示，待测试节点ID为0x439。当被网络中的0x43A节点唤醒后，节点0x439从总线休眠状态进入网络唤醒状态中的正常发送状态，并发出第1帧网络管理报文，之后按照500ms的发送周期发送网络管理报文。发送完成3帧网络管理报文后，正常发送状态定时器到时，进入到正常模式状态，正常模式状态与重复报文状态中的正常发送状态报文周期相同，同样按照500ms的发送周期发送网络管理报文。
图6 网络唤醒策略测试结果
END
