AUTOSAR标准的CAN网络休眠异常诊断机制研究

电子设计联盟 · 发表于 2024-6-6 12:01:00

mknmaja5c1r6403402821.png

摘要：汽车网络管理旨在保证节点间的通信状态同步及网络故障检测，是可靠的车载网络的重要组成部分。针对AUTOSAR网络管理中对于偶发的休眠异常难以定位与复现的问题，提出了一种基于唤醒链的网络休眠异常诊断机制，将管理报文在网络中出现的先后顺序与节点唤醒的先后顺序相对应，通过在网络管理报文中携带位置信息，实时记录网络节点在唤醒链中的位置，在偶发性故障出现时，将相关信息存入非易失性内存，之后通过重建唤醒链，恢复故障发生时网络中各节点的唤醒顺序及相关运行状态信息，帮助更准确高效地定位引发故障的节点，一定程度上解决了休眠异常难以复现和检测的问题。同时利用控制器局域网络CAN总线在实验平台CANoe上验证了该方法的有效性。
现代汽车更安全、更舒适、更智能的代价是车载ECU（electronic control unit）数量的迅速增长，导致汽车系统设计愈加复杂，控制器兼容性问题越加明显[1]，控制器软件开发成本日益增加。全球知名的汽车制造商、零部件供应商及其他电子、半导体和软件系统公司联合研发了一种开放的、行业标准化的汽车嵌入式软件架构AUTOSAR。AUTOSAR对汽车基础软件做了标准化定义，提升了汽车控制器的兼容性、复用性和可靠性。（培训预告：6月13日国际CiA协会汽车CAN总线实训开班）
在汽车的实际应用过程中，由于软件漏洞或硬件失效[2]等异常因素造成的控制器无法正常休眠的事件时常发生。特别是随着智能网联汽车[3]的兴起，在车辆静置的情况下仍然会有总线通信的需求，休眠唤醒的频次增多，造成异常事件出现的几率增加。车辆休眠异常带来的是车辆的静态能耗成倍地增加，导致汽车蓄电池馈电，进而引发蓄电池寿命缩短、发动机无法正常启动等诸多问题。这给客户对车辆的使用带来极大的不便，虽然维修人员可以通过汽车诊断设备分析网络报文来诊断网络引发的故障，但是由于汽车偶发的休眠异常故障很难复现，导致难以定位到异常的控制器，所以即使更换蓄电池也不能从根本上解决问题。
在研究AUTOSAR网络管理机制不足的情况下，对节点故障、总线关闭处理以及节点协同工作进行研究，提出了一种基于唤醒链的休眠异常检测机制，通过在网络管理报文中携带位置信息，实时记录网络节点在唤醒链中的位置，当偶发性故障出现时，将相关信息存入非易失性内存中，之后通过重建唤醒链，恢复故障发生时网络中各节点的唤醒顺序和工作状态，为维修工作人员提供更多信息，在一定程度上解决了休眠异常难以复现和故障定位的问题。
1 关联研究
CANoe是由Vector公司开发的一款集CAN总线应用开发、总线测试和总线分析等功能为一体的工程软件。CANoe 能支持FlexRay、CAN、J1939、以太网等多种网络的开发测试，能提供在总线网络设计过程中所需的模型创建、数据库创建、仿真测试、监控、检测、记录等功能[4]。汽车电子行业有很多研究尝试实时检测网络中的休眠异常故障，以提高汽车电子系统的可靠性。
文献[5]使用CANoe将网络管理报文映射为节点通信状态并可视化显示，帮助检查网络管理配置的缺陷，为AUTOSAR 标准的网络通信验收测试提供相关的设计指南。该研究需要在发现问题后离线状态下，借助诊断工具定位问题节点，定位过程较为复杂。文献[6]通过添加故障处理状态对节点发送或接收报文故障进行处理，但是没有指出节点故障后，后续如何根据网络状态进行相应的活动，且没有总线关闭处理措施。文献[7]在CAN 总线的基础上提出一种节点故障检测方法，在网络管理状态机中增加EEROR MODE状态，根据网络管理报文收发的错误次数判断是否发生故障，进入该状态并对故障节点进行快慢恢复通信，该研究的重点是故障的恢复和节点的协同工作，无法帮助定位异常控制器。文献[8]通过实际的故障案例分析提出一种基于OSEK网络管理的汽车馈电检测方法，该方法的关键是通过网络报文分析找到网络的唤醒源，即网络中第一个唤醒的节点，然后针对唤醒源进行电路分析排查故障。该方法虽然可以检测到网络管理异常，但是其效果过于依赖人工，十分耗时，且过度依赖维修人员经验，效果不佳。文献[9]提出一种基于OSEK 网络管理逻辑环的偶发休眠异常检测方法，该方法令逻辑环上的待休眠节点检测其后继节点是否在规定的时间内休眠，如果后继节点没有按时休眠则记录其发生休眠异常。该方法依赖于OSEK 规范的逻辑环机制。目前学者对于OSEK 网络管理的研究相对较多，对于AUTOSAR网络管理的研究更多在于协议栈的本身实现以及故障恢复疏通等方面，而故障疏通更多的是依靠硬件本身的功能，对于节点异常休眠及故障定位方面做出相关研究较少。
2 网络管理概述
2.1 AUTOSAR网络管理协议栈
目前主流的网络管理标准有OSEK[10-11]和AUTOSAR两种，AUTOSAR在OSEK的基础上发展而来。AUTOSAR网络管理基于周期性网络管理报文[12]，通过广播传输由集群中的所有节点接收。接收到网络管理报文表明发送节点希望保持网络管理集群处于唤醒状态。如果任何节点已准备好进入总线-休眠模式，它将停止发送网络管理报文，但只要接收到来自其他节点的网络管理报文，它就会推迟进入到Bus Sleep模式。最后，如果经过一定时间再没有接收到网络管理报文，则每个节点都会进入到Bus Sleep模式。然而AUTOSAR网络管理是一种分布式直接网络管理[13]，网络中的节点之间不存在网络管理层次的唤醒依赖或优先级关系，导致无法直接将其直接用于休眠异常检测，定位故障源头。
CAN总线是目前汽车领域中应用最为广泛的汽车总线，本文的研究对象为基于CAN 总线的AUTOSAR网络管理协议栈。图1为符合AUTOSAR规范[14-20]的网络管理软件架构。

v3aipac13xk6403402922.jpg

图1 AUTOSAR网络管理协议栈
Fig.1 AUTOSAR network management stack
ComM 模块负责简化用户对网络管理和总线通信状态的控制，能够协调多个用户对通信信道的申请和释放请求，从而提供信道复用功能。
CANSM 模块负责根据ComM 的通信请求设置CAN 控制器和收发器的工作状态，从而同步信道的通信状态和通信设备的工作状态。
NMIf 模块封装了不同类型总线网络管理的接口，向ComM 提供网络管理的统一访问接口。通常汽车内部存在不同类型的总线，且总线的网络管理协议各不相同，因此需要NMIf提供统一的访问接口。在CAN网络管理协议栈中，NMIf 负责将ComM 的通信请求传递给CANNM，以及将CANNM的网络通知传递给ComM。
CANNM是AUTOSAR CAN网络管理协议栈的核心功能模块，负责管理节点的网络状态，向ComM 提供依赖于CAN 总线的网络管理服务。CANNM 能够接受ComM的网络请求和释放请求，处理接收到的网络报文以及将网络状态的变化通知给ComM。
CANIF模块屏蔽了底层CAN控制器和收发器的访问接口，向CANSM 提供CAN 设备的统一状态管理接口，向CANNM提供CAN设备的统一通信访问接口。
CANDrv模块负责控制CAN控制器的工作状态，向CANIF 提供CAN 控制器的状态管理和通信访问接口。CANTrcv 模块负责控制CAN 收发器的工作状态，向CANIF提供CAN收发器的状态管理接口。
综上所述，ComM模块为用户提供信道通信管理服务，CANSM 模块为ComM 提供信道CAN 设备管理服务，CANNM 模块为ComM 提供CAN 网络管理服务。上述模块各自设计了自动状态机，通过状态机记录当前状态、服务请求和通知事件，并通过周期调用模块主函数处理请求和事件。
2.2 CAN网络管理状态机
根据AUTOSAR 网络管理规范，网络管理状态机分为三个模式bus-sleep mode、prepare bus-sleep mode和network mode，如图2所示。

l1mozsdr0sc6403403022.jpg

图2 网络管理状态机
Fig.2 Network management state machine
Bus-sleep mode：总线休眠模式，网络中节点都处于休眠模式，节点的网络管理报文和应用报文禁止发送，并且不能对总线上的报文进行ACK应答。
Network mode：网络模式，网络中节点都处于唤醒状态，该模式又包含三个子状态，分别为：（1）normal operation state（NOS），正常操作状态，节点处于主动唤醒状态，周期发送网络管理报文来保持网络唤醒状态；（2）ready sleep state（RSS），等待休眠状态，节点处于被动唤醒状态，不会发送网络管理报文但是会因接收到网络管理报文而无法休眠；（3）repeat message state（RMS），重复报文状态，周期发送重复网络管理报文通知其他节点自身的存在。
Prepare bus-sleep mode：预休眠模式，网络中节点都处于静默模式，节点的网络管理报文和应用报文禁止发送，但应该对总线上的报文进行ACK应答。
在总线休眠模式下，如果收到唤醒请求，会进入网络模式，状态机进入网络模式是默认切换到重复报文状态，启动周期报文定时器，定时发送网络报文，同时启动重复报文状态定时器，等待定时器到期离开重复报文状态。
主动唤醒节点离开重复报文状态进入正常操作状态，周期发送网络报文；被动唤醒节点则进入等待休眠状态，停发网络报文。在正常操作状态如果上层模块通过CanNm_NetworkRelease 接口主动释放唤醒请求，则进入等待休眠状态。
进入等待休眠状态时，启动网络定时器，（节点收到网络报文会重置该定时器），定时器到期后会从等待休眠状态切换到总线预休眠模式。
在预休眠模式下如果收到网络报文或其他唤醒请求，会重新进入网络模式，否则的话等待预休眠定时器到期后进入总线休眠模式。
2.3 CAN网络节点的唤醒与休眠
由于汽车电池容量有限，对于常火供电的ECU，如防盗开关、远程定位系统、远程升级系统等，需要适时切换到休眠模式以节省电量。网络管理的目的就是同步网络中常火供电ECU 的工作模式，使ECU 在汽车熄火后同步休眠从而降低整车的静置功耗，同时在ECU 需要提供服务时同步唤醒其他ECU。
AUTOSAR 网络管理中的节点通过周期性广播网络管理报文来实现节点状态监控、节点故障检测、节点协同休眠等功能[21]。网络管理报文是一组特殊定义的总线报文，例如CAN NM就是通过报文ID区分网络管理报文和应用报文。NM 管理的对象是网络中的通信节点（Node），但并不是总线上所有的节点都属于同一网络。图3，Node_1、Node_2和Node_3的网络管理报文ID 范围为[0x10，0x1F]，Node_4 和Node_5 的网络管理报文ID 范围为[0x20，0x2F]，因此Node_1、Node_2 和Node_3是同一网络，而Node_4和Node_5属于另一个网络。范围不同的两组节点的网络管理报文无法同步。

21afa5f5fgx6403403122.jpg

图3 总线上的不同网络
Fig.3 Different networks on bus
当网络中的节点请求通信服务时，NM将通过网络管理报文唤醒网络中的其他节点，进而同步网络中节点的唤醒状态。主动请求通信服务的节点为主动唤醒节点，将会周期发送网络管理报文来维持网络唤醒状态；而被动参与网络通信的节点为被动唤醒节点，不会发送网络管理报文。直到所有主动节点都满足休眠条件并停止发送网络管理报文后，网络中的节点才能进入休眠状态。
网络中节点的主动和被动唤醒状态是可以相互切换的。当主动唤醒的节点满足休眠条件后将会释放通信请求并停止发送网络管理报文，此时节点从主动唤醒状态变为被动唤醒状态。同理，当被动唤醒节点主动请求通信服务时，将会周期发送网络管理报文来维持网络的唤醒状态，此时节点从被动唤醒状态变为主动唤醒状态。
3 休眠异常诊断设计与分析
3.1 休眠异常检测原理
通过拓展符合AUTOSAR 规范的网络管理协议栈来实现基于唤醒链的休眠异常检测机制，该机制的假设条件包括：网络中更早主动唤醒的节点通常更有可能是休眠异常的原因，前一个节点异常休眠可能会导致后面节点异常休眠；主动唤醒节点请求网络休眠后，网络应在预期时间内休眠。
通过网络报文实时记录网络中节点的唤醒顺序，并借助休眠超时定时器判断网络是否发生休眠异常。当节点的休眠超时定时器到期时，广播休眠异常报文通知休眠异常，并将当下的网络中节点的唤醒顺序及相关信息存入非易失性内存（通过配置NV Block，调用AUTOSAR存储协议栈的接口将其存入Flash中）。
各节点的网络管理报文在网络中出现的先后顺序对应网络节点唤醒的先后顺序，在唤醒链中每个节点的网络报文都记录自身当前唤醒ID，即该节点在唤醒链中的位置，并在网络管理报文中携带自身节点唤醒ID。因此，当节点接收到网络管理报文后，根据自身状态和报文的唤醒ID计算得到自身的唤醒ID。网络中第一个主动唤醒节点的唤醒ID为0，后续主动唤醒节点序号自增，而被动唤醒节点始终位于唤醒链尾部，从而在网络中建立记录节点唤醒先后顺序的唤醒链。主动唤醒的节点一般不会调整自身的唤醒ID，除非先前唤醒的节点主动释放通信，后续的节点才会进行唤醒链调整。
唤醒链原理如图4 所示。主动节点接收到网络管理报文后直接丢弃报文即可，因为主动节点已经确认在唤醒链中的位置，因此不需要再做修改。被动节点始终记录网络中最大的唤醒ID，当被动节点请求网络通信时设置唤醒ID 为网络中最大唤醒ID+1 即可。除此之外，主动节点满足休眠条件后可以发送一帧特殊的网络管理报文通知其他节点，如果待休眠节点的唤醒ID 小于节点自身的唤醒ID 则设置自身的唤醒ID 减1，避免唤醒链节点缺失。

prstnujs4wn6403403222.jpg

图4 唤醒链算法原理
Fig.4 Wake-up chain algorithm principle
如图5 所示为唤醒链的建立和调整过程。假设网络中有A、B、C三个节点，依次主动参与网络管理。

gekiqh222cv6403403322.jpg

图5 唤醒链示意图
Fig.5 Wake-up chain diagram
节点B 在用户释放通信请求时广播休眠报文并进入准备休眠状态。节点C在接收到B的休眠报文时，判断B的唤醒ID小于自身的唤醒ID，设置自身唤醒ID减1，从而让唤醒链实时调整网络中节点的唤醒顺序。节点B 在进入等待休眠状态时根据配置参数启动休眠超时定时器，如果在休眠超时定时器到期前离开等待休眠状态则停止休眠超时定时器，否则在到期后广播休眠异常报文通知其他节点，每个接收到休眠异常报文的主动唤醒节点都会记录休眠异常信息，包括节点唤醒ID、节点ID以及异常报文源节点ID等。
3.2 休眠异常检测算法实现
3.2.1 算法存在问题及解决方法
本研究提出的唤醒链算法可根据网络管理报文出现顺序决定唤醒顺序，并随着网络中节点的唤醒和休眠进行唤醒链的调整，实时描述网络中的唤醒依赖关系，记录网络中节点的唤醒顺序从而定位异常节点。但是在实现时需要考虑以下问题：
（1）由于主动唤醒的节点会根据当前网络中的最大唤醒ID 来计算自身唤醒ID，网络中同时主动唤醒的节点具有相同的最大唤醒ID，这就导致节点设置自身的唤醒ID相同，此时唤醒链的单链结构被破坏。
（2）由于网络中的唤醒链已经建立，因故障离线的节点在主动唤醒时可能会错误地设置自身的唤醒ID，导致网络中的唤醒链失效。
问题（1）可能导致唤醒链出现分叉现象，破坏唤醒链的单链结构。唤醒链分叉本身不会产生故障，但是如果后续节点主动唤醒，那么当分叉节点满足休眠条件时会产生如图6所示的故障：原本在节点C之后唤醒的节点D 因收到节点B 的休眠通知，调整自身的唤醒ID 与节点C相同，导致唤醒链失效。

j1uivlwmjqe6403403422.jpg

图6 唤醒链分叉示例图
Fig.6 Wake up chain fork example diagram
为解决问题（1），设计了唤醒链分叉调整算法，当节点通过网络管理报文检测到相同唤醒ID 的其他节点时，比较两个节点ID，两者中节点ID较大的节点的唤醒ID 自增，从而保持唤醒链的单链结构。该设计在本质上是将同时唤醒的节点按照节点ID升序排列设置唤醒ID，但是由于唤醒链是分布式存储结构，因此只能依赖于网络管理报文进行唤醒链调整。
举例解释相同唤醒链ID 时的调整算法，假设网络中有三个同时从总线休眠状态主动唤醒的节点A、B和C，节点ID分别为0x10、0x20和0x30。如果按照3.2.3小节介绍的唤醒链建立算法执行，则三个节点的唤醒ID都被设置为0，此时唤醒链出现分叉问题。采用唤醒链分叉调整算法时，则网络中节点的唤醒链调整如图7所示，当节点B和C收到节点A的网络管理报文时发现A的唤醒ID和自身的唤醒ID相同，且A的节点ID小于自身的节点ID，故将自身唤醒ID加1。同理当节点C收到节点B的网络管理报文时，也会因唤醒优先级低而设置自身唤醒ID加1。

ryxsgaynmp46403403522.jpg

图7 唤醒链分叉调整示意图
Fig.7 Wake-up chain fork adjustment diagram
上述方法可以在有限个网络管理报文发送周期内，让网络中具有相同唤醒ID的节点按照节点ID大小按顺序设置唤醒ID，从而解决唤醒链的分叉问题。若在唤醒链调整阶段有新的节点主动唤醒，由于唤醒链调整时间较短，可以认为后续唤醒的节点同之前的节点是同步唤醒的关系，主动唤醒的新节点将会加入到唤醒链的调整中，而不能直接作为唤醒链的尾部节点。
网络中的节点可能因自身故障或网络问题暂时离线，并在节点恢复后主动参与网络。由于离线节点对当前的唤醒链情况并不了解，因此如果按照前面的算法执行，当离线节点主动参与网络管理时会出现两种情况：节点尚未接收到任何网络管理报文，因此设置自身唤醒ID 为0；节点接收到某个网络管理报文，并设置最大唤醒ID 为该网络管理报文携带的唤醒ID，并设置自身唤醒ID为最大唤醒链ID加1。
因此，问题（2）会导致离线节点错误地加入唤醒链，造成唤醒链的失效。此外，如果采用上文中的唤醒链分叉调整算法，则问题（2）有可能会造成唤醒链的完全失效。举例解释问题（2）造成的唤醒链失效，假设网络中存在4 个主动唤醒的节点A、B、C 和D，节点ID 分别为0x10、0x20、0x30和0x40。如图8所示，当离线节点B主动唤醒时设置自身唤醒ID为0，经过唤醒链分叉调整后节点B的唤醒链ID为1，节点C和D因B的错误插入而后移失效。

s3h0rvvtfhs6403403622.jpg

图8 离线节点唤醒问题
Fig.8 Offline node wakeup problem
问题（2）的根本原因是在离线节点唤醒时不能正确得到网络中的最大唤醒ID，因此设计节点在刚进入network-mode模式时设置唤醒ID为无效唤醒ID（0xFF），并在RMS状态通过收集网络管理报文来更新记录网络中有效的最大唤醒ID。当节点离开RMS 状态进入NOS 状态时，根据收集到的网络中最大唤醒ID 来设置自身的唤醒ID：如果记录的最大唤醒ID为无效唤醒ID（0xFF），说明此时网络中，没有在该节点之前唤醒的节点，设置当前节点唤醒ID 为0，否则设置当前节点唤醒ID为最大唤醒ID加1。
3.2.2 网络管理报文设计
CAN 网络管理报文包含源节点ID、控制位向量和用户数据。源节点ID（Byte0）：每个节点都被静态分配网络中唯一的节点ID。当节点接收到网络管理报文时，可以通过报文的源节点ID 获得发送节点的身份。控制位向量（Byte1）：节点的通信状态标识。用户数据（Byte2～Byte7）：允许携带用户自定义数据。
休眠异常检测机制需要通过网络管理报文建立和调整唤醒链，因此需要对原有的网络管理报文格式进行拓展设计，并根据控制位向量设计以下四种网络管理报文。
（1）重复网络管理报文标志位repeat message（Bit0）：网络管理状态机在RMS状态时周期发送重复网络管理报文。该报文的唤醒源ID仅用于同步网络中最大唤醒ID，避免离线节点主动唤醒时设置了无效的唤醒ID。
（2）正常网络管理报文标志位active wakeup（Bit4）：网络管理状态机在NOS状态时周期发送的正常网络管理报文。该报文的唤醒ID用于唤醒链分叉调整和同步最大唤醒链ID。
（3）休眠正常报文标志位ready sleep（Bit5）：主动唤醒节点满足休眠条件进入RSS状态前，广播休眠正常报文通知其他节点进行唤醒链调整。所有唤醒ID大于休眠报文唤醒ID 的节点都将唤醒ID 减1，避免唤醒链节点缺失。
（4）休眠异常报文fault sleep（Bit6）：主动唤醒节点满足休眠条件并进入RSS 状态时启动休眠超时定时器。当休眠超时定时器到期时，将会广播休眠异常报文通知其他节点存在休眠异常。该报文的异常通知编号用于区分同一节点的休眠异常通知，节点每次广播休眠异常报文，其异常通知编号加1。
3.2.3 唤醒链算法实现
对网络管理状态机和服务接口进行拓展，以满足休眠异常检测机制的需求。在唤醒链算法中每个节点都存储自身的唤醒ID和网络中最大的唤醒ID，并以0xFF作为无效的唤醒ID。
对请求主动通信接口CanNm_NetworkRequest（）和释放通信请求接口CanNm_NetworkRelease（）进行补充性设计来满足休眠异常检测机制的要求。
CANNM 模块通过主动唤醒请求标志位来判断主动和被动唤醒，因此需要为网络管理状态机定义主动唤醒标志。当调用CanNm_NetworkRequest（）接口时将主动唤醒标志置1，表示节点当前处于主动唤醒状态。当节点需要进入RSS状态时，只有主动唤醒标志为1时才启动休眠超时定时器，当休眠超时定时器到期时清空主动唤醒标志位。上层模块调用CanNm_NetworkRelease（）接口后，节点将进入RSS状态。在主动唤醒节点满足休眠条件时要广播一帧休眠正常报文通知其他节点进行唤醒链调整，因此需要修改CanNm_NetworkRelease（）接口实现来支持休眠异常检测，如图9所示。

lgqjuxjabzz6403403722.jpg

图9 NetworkRelease（）接口设计
Fig.9 NetworkRelease（）interface design
主动唤醒节点调用CanNm_NetworkRelease（）接口时就满足了休眠条件，因此在该接口中主动发送休眠正常报文，设置该节点唤醒ID无效，并重载休眠超时定时器值。如果当前处于NOS 状态则直接切换到RSS 状态，否则就是处于RMS 状态等待repeat message timer定时器到期才进入RSS状态。
对CANNM 网络管理状态机的状态动作进行补充性设计，在不破坏原本状态机的前提下增加休眠异常检测机制，改进的网络管理状态机如图10所示。

xyk20utxwsx6403403822.jpg

图10 支持休眠异常检测的网络管理状态机
Fig.10 Network management state machine supporting sleep anomaly detection
图中通过标签注明各个状态和状态切换时唤醒链的调整行为，具体流程如下：
步骤1 状态机初始化后进入bus-sleep mode 模式并初始化节点的唤醒链信息，即设置节点自身的唤醒ID和网络中的最大唤醒ID无效值（0xFF）。
步骤2 在network mode模式下同步网络中的最大唤醒ID，并根据网络中的最大唤醒ID 设置节点自身的唤醒ID。
步骤3 在network mode模式下收到休眠正常报文时进行唤醒链休眠调整，从而避免唤醒链节点缺失。
步骤4 进入NOS 状态时更新节点的唤醒ID，从而解决3.2.1小节提出的问题（2）。
步骤5 在NOS 状态和RMS 状态下收到唤醒ID 相同的报文时，执行唤醒链分叉调整算法，从而解决3.2.1小节提出的问题（1）。
步骤6 进入RSS状态时，如果检测到主动唤醒标志置1 且休眠超时定时器值有效，则启动休眠超时定时器。休眠超时定时器仅在RSS状态计数，当定时器到期时广播休眠异常报文、清空主动唤醒标志并将异常通知编号加1。节点接收到休眠异常报文时将自身唤醒ID、报文源节点ID和异常通知ID存储到非易失性内存。
上面详细介绍了如何在网络管理状态机中实现休眠异常检测机制，其中网络唤醒链的调整和异常通知都是通过网络管理报文传递。节点接收到网络管理报文后，通过解析报文的控制位向量确定报文类型，并根据报文类型执行不同的唤醒链算法：接收到休眠异常报文时记录休眠异常事件，接收到正常休眠报文时执行休眠调整算法，接收到重复和正常网络管理报文时，首先执行最大唤醒链同步算法，然后判断是否存在唤醒链分叉问题，如果存在则执行唤醒链分叉调整算，否则直接返回。
4 实验验证
本章对网络管理的同步唤醒和休眠功能，以及休眠异常检测机制进行功能测试。
4.1 实验系统设计
如图11 所示，CAN 网络管理实验系统由两部分构成：3 个CAN 网络管理节点和CANoe 网络检测平台，3个节点分别定义为ECU1、ECU2和ECU3。

slpo12etjzc6403403922.jpg

图11 实验系统示意图
Fig.11 Schematic diagram of experimental system
实验系统中的CAN 网络管理节点采用恩智浦的MPC5748G 作为主芯片，配合TJA1145 CAN 收发器实现支持网络管理报文唤醒功能的网络节点。采用C 语言在各个网络管理节点上设计实现CAN网络管理协议栈，使其能够同步节点通信状态，支持总线负载功能和休眠异常检测机制。
实验系统采用VN1630A 将CANoe 和实际CAN 总线连接，通过CANoe 对总线上的节点进行实时监控，CAN 总线波特率为500 kbit/s。通信网络的实际节点ID、网络管理报文ID 和状态报文ID 如表1 所示，其中CAN网络管理报文的用户数据长度为0。
表1 节点报文ID表
Table 1 Node message ID table

rcp4ahwwyej6403404023.jpg

同时定义5种状态报文，分别对应网络管理状态机的5种通信状态，如表2所示。
表2 节点通信状态表
Table 2 Node communication status table

xwdifhjzhte6403404123.jpg

1 `- M6 [9 F! J" o8 S
4.2 同步唤醒和休眠功能验证

通过对节点通信状态的实时检测，验证CANNM同步唤醒和休眠节点的功能。

在验证同步唤醒和休眠功能时为了实时获得节点的通信状态，定义网络管理总线以外的节点状态也需要通知总线，如图12 所示。在实验系统中节点通知状态变化的信道始终保持正常通信状态，当节点网络管理信道的通信状态改变时，立即发送状态报文通知节点的状态变化。

q1kauwbh4mt6403404224.jpg

图12 同步唤醒和休眠功能验证系统
Fig.12 Simultaneous wake-up and sleep function verification system
网络中节点的四个定时器参数应该保持一致才能确保节点同步唤醒和休眠，本节实验中各个节点的定时器值如表3所示。

表3 节点网络管理参数
Table 3 Node network management parameters 单位：ms

f54lkpd3ppi6403404324.jpg

同步唤醒功能验证的测试程序流程：ECU_1上电后主动唤醒，ECU_2 和ECU_3 被动唤醒。如图13 所示，ECU_1 主动唤醒后进入RMS 状态，随后ECU_2 和ECU_3 也进入RMS 状态，成功验证同步唤醒功能。所有节点在RMS 状态下保持40 ms 的重复报文时间后，ECU_1 因主动唤醒进入NOS 状态，ECU_2 和ECU_3 因被动唤醒进入RSS状态。

v1mre0bgpaa6403404424.jpg

图13 同步唤醒测试
Fig.13 Synchronized wake up test
同步休眠功能验证的测试程序流程：如图14所示，ECU_1 在唤醒400 ms 后释放主动唤醒请求并进入RSS状态，等待40 ms 后进入prepare bus-sleep mode 模式，等待60 ms的等待总线休眠时间后进入bus-sleep mode模式。从图中可以看出三个节点在小于5 ms的误差内同步进入bus-sleep mode模式，成功验证同步休眠功能。

kh2fsecybyv6403404524.jpg

图14 同步休眠测试
Fig.14 Synchronized sleep test
整个实验流程中CANoe捕获到的网络管理报文如图15 所示，每个节点在RMS 状态下都发送两帧重复网络管理报文，其中ECU_1 在离开RMS 状态后以20 ms为周期发送网络管理报文。ECU_1 发送的重复网络管理报文的控制位向量为0x11，其中repeat message bit和active wakeup bit 都置1，而ECU_2 发送的重复网络管理报文的控制位向量为0x01，其中仅repeat message state bit置1。图中ECU_1在RSS状态等待的时间小于预设的超时时间60 ms，这是因为每次发送或接收到网络管理报文时就重置超时计数器，因此ECU_1 是在发送完成一帧网络管理报文后的20 ms 时释放主动唤醒请求，导致仅在RSS状态等待40 ms。

komxsreup036403404625.jpg

图15 网络管理报文记录
Fig.15 Network management message record
4.3 休眠异常检测机制验证
通过测试用例验证休眠异常检测机制，网络中节点的时间参数同表3。验证结果如下：ECU_1 上电复位后主动唤醒，ECU_2 和ECU_3 被动唤醒。ECU_1主动唤醒网络中的其他节点，并在网络中建立唤醒链。ECU_1、ECU_2 和ECU_3 在初始化后设置唤醒ID 无效，即为0xFF，并在RMS 状态执行最大唤醒链同步算法。从图16 中可以看到3 个节点的重复网络管理报文的唤醒ID 均为0xFF，因此节点在离开RMS状态时最大唤醒ID为无效唤醒链ID，故ECU_1设置自身唤醒ID为0。

zjtilaygd2n6403404725.jpg

图16 ECU1主动唤醒
Fig.16 ECU1 actively waking up
ECU_2 和ECU_3 在被动唤醒后100 ms 时主动唤醒。ECU_2 和ECU_3 在主动唤醒时首先通过唤醒ID更新算法设置各自的唤醒ID。在此之前网络中只有ECU_1主动唤醒，网络中最大唤醒ID为0，故ECU_2和ECU_3 主动唤醒时设置唤醒ID 为1。此时由于ECU_2和ECU_3 的唤醒ID 相同，通过唤醒链分叉调整算法将ECU_3的唤醒ID设置为2，如图17所示，在一个报文发送周期内ECU_2和ECU_3完成唤醒链分叉调整。

图17 ECU_2和ECU_3主动唤醒
Fig.17 ECU2 and ECU3 actively waking up
ECU_1 主动唤醒400 ms 后释放唤醒请求，设置休眠定时器超时时间为200 ms，根据前文设计的CanNm_NetworkRelease（）接口，在ECU_1释放主动唤醒请求时发送了一帧休眠正常报文，其控制位向量的Ready Sleep Bit置1（0x20）；当ECU_2和ECU_3接收到ECU_1的休眠正常报文时执行休眠调整算法调整各自的唤醒ID，如图18 所示，ECU_2 的唤醒ID 变为0，ECU_3 的唤醒ID 变为1。ECU_1 在进入RSS 状态时将启动休眠超时定时器，实验中该定时器的值为200 ms，该值仅用于实验测试。

图18 ECU_1释放网络请求
Fig.18 ECU1 releasing network request
由于ECU_2 的休眠异常导致ECU_3 和ECU_1 无法正常休眠。ECU_1 的休眠超时定时器到期时广播了一帧休眠异常报文，其控制位向量中的fault sleep bit置1（0x40），如图19所示。

图19 发生休眠异常
Fig.19 Sleep exception occuring
由于ECU_1 首次发送休眠异常报文，因此其异常报文编号为0。ECU_2 和ECU_3 收到休眠异常报文后记录自身唤醒ID、报文源节点ID 和异常报文编号并存入非易失性内存，如表4所示。

表4 休眠异常信息记录
Table 4 Sleep exception information record

从所有节点的非易失性内存中读取休眠异常记录，将休眠异常记录根据休眠异常报文源节点ID和报文编号分组，进而还原休眠异常发生时网络中各节点的唤醒顺序。

可以推断ECU_2和ECU_3在发生休眠异常时存在图20 所示的唤醒依赖关系，因此ECU_2 被视为最有可能的故障节点，唤醒顺序并不能完全作为休眠异常节点的判定标准，但也足以帮助维修人员和汽车用户了解到汽车可能存在的休眠异常故障问题，并进行针对性的检查和修复。

图20 唤醒顺序还原
Fig.20 Wake up sequence restoring
5 结束语
目前汽车行业正处于电子化、智能化和信息化发展的重要阶段，研究车载网络管理和通信机制对汽车电子系统发展具有重大意义。针对网络管理偶发性休眠异常问题，提出一种基于唤醒链的AUTOSAR CAN 网络管理休眠异常检测机制，通过分析网络管理状态机讨论该机制的可行性，在网络管理模块上设计并实现了该机制，同时搭建实验系统验证了设计的有效性。未来研究工作可进一步研究网络管理状态机及时间参数的正确性，拓展唤醒链算法以用于离线节点检测等功能，并且需要针对多种类型的汽车总线如FlexRay、LIN、MOST等进行扩展和验证。
参考文献：
[1]黄韬,刘江,汪硕,等.未来网络技术与发展趋势综述[J].通信学报,2021,42(1):130-150.HUANG T,LIU J,WANG S.Overview of future network technology and development trends[J].Journal of Communications,2021,42(1):130-150.
[2]李舟军,张俊贤,廖湘科,等.软件安全漏洞检测技术[J].计算机学报,2015,38(4):717-732.LI Z J,ZHANG J X,LIAO X K.Software security vulnerability detection technology[J].Chinese Journal of Computers,2015,38(4):717-732.
[3]呼布钦,秦贵和,刘颖,等.下一代汽车网络:车载以太网技术现状与发展[J].计算机工程与应用,2016,52(24):29-36.HU B Q,QIN G H,LIU Y,et al.Next generation automotive network: technology status and development of automotive Ethernet in-vehicle network[J].Computer Engineering and Applications,2016,52(24):29-36.
[4]吴祥.汽车FlexRay 网络中AUTOSAR 网络管理机制的研究[D].合肥:合肥工业大学,2015.WU X.Research on AUTOSAR network management mechanism in automotive FlexRay network[D].Hefei: Hefei University of Technology,2015.
[5]THIYAGARAJ A.Parasitic battery drain problems and AUTOSAR acceptance testing[J].SAE International Journal of Passenger Cars-Electronic and Electrical Systems,2018,11:139-147.
[6]张建军,于萍,张本宏,等.一种改进的AUTOSAR 车载网络管理方法[J].电子测量与仪器学报,2013,27(11):1093-1098.ZHANG J J,YU P,ZHANG B H,et al.An improved AUTOSAR vehicle network management method[J].Journal of Electronic Measurement and Instrumentation,2013,27(11):1093-1098.
[7]万兴,蒋峥,谢斌.AUTOSAR标准CAN总线故障处理和节点协同策略研究[J].计算机工程与应用,2018,54(21):84-89.WAN X,JIANG Z,XIE B.AUTOSAR standard CAN bus fault handling and node collaboration strategy research[J].Computer Engineering and Applications,2018,54(21):84-89.
[8]张新宇,李朋飞,周红英,等.车辆CAN网络休眠异常监控方法研究[J].汽车实用技术,2020,45(17):87-89.ZHANG X Y,LI P F,ZHOU H Y,et al.Research on monitoring method of vehicle CAN network dormancy abnormality[J].Automotive Practical Technology,2020,45(17):87-89.
[9]何烈炎,韩伟.基于OSEK 网络管理的车辆馈电检测方法研究[C]//2015 年海南机械科技学术年会论文集,2015.HE L Y,HAN W.Research on vehicle feed detection method based on OSEK network management[C]//Proceedings of the 2015 Hainan Machinery Science and Technology Annual Conference,2015.
[10]章亮飞,李银国.嵌入式实时操作系统AutoOSEK的设计[J].计算机工程,2007,33(16):53-55.ZHANG L F,LI Y G.Design of embedded real-time operating system AutoOSEK[J].Computer Engineering,2007,33(16):53-55.
[11]LI Y W,GONG J F,ZHANG H W,et al.Design of automotive CAN network management based on OSEK standard[C]//Proceedings of 2011 International Conference on Electronic &Mechanical Engineering and Information Technology,2011:717-721.
[12]周霖.基于AUTOSAR 标准的网络管理栈—SmartSAR NM的设计与实现[D].杭州:浙江大学,2011.ZHOU L.Design and implementation of network management stack based on AUTOSAR standard-SmartSAR NM[D].Hangzhou:Zhejiang University,2011.
[13]郭中飞.面向智能汽车的车载网络实时管理机制研究[D].合肥:合肥工业大学,2019.GUO Z F.Research on real-time management mechanism of vehicle network for smart vehicles[D].Hefei:Hefei University of Technology,2019.
[14]AUTOSAR GBR.Specification of communication manager R4.0.3[S].AUTOSAR GbR,2013.
[15]AUTOSAR GBR.Specification of network management interface R4.0.3[S].AUTOSAR GbR,2013.
[16]AUTOSAR GBR.Specification of CAN network management R4.0.3[S].AUTOSAR GbR,2013.
[17]AUTOSAR GBR.Specification of CAN state manager R4.0.3[S].AUTOSAR GbR,2013.
[18]AUTOSAR GBR.Specification of CAN interface R4.0.3[S].AUTOSAR GbR,2013.
[19]AUTOSAR GBR.Specification of CAN transceiver driver R4.0.3[S].AUTOSAR GbR,2013.
[20]AUTOSAR GBR.Specification of CAN driver R4.0.3[S].AUTOSAR GbR,2013.
[21]张亚生.基于AUTOSAR的汽车FlexRay网络通信管理研究[D].合肥:合肥工业大学,2016.ZHANG Y S.Research on automotive FlexRay network communication management based on AUTOSAR[D].Hefei:Hefei University of Technology,2016.
加入AUTOSAR交流群
添加请备注公司+姓名

END

AUTOSAR标准的CAN网络休眠异常诊断机制研究

发表回复

精选推荐

浏览过的版块