从整车层级到零部件层级的网络管理开发
汽车
2024-10-11 08:50
广东
![]()
对于网络管理（Network Management）特别是AUTOSAR 网络管理在行业内大家已经熟知，对于其状态跳转逻辑及睡眠唤醒策略多少都有所了解，但是回到最初的目的，为什么需要网络管理，怎么从整车层级定义那些ECU要做网络管理，AUTOSAR NM协议栈如何实现ECU的休眠/唤醒，以及如何协调域控ECU多路网络管理总线的休眠和唤醒， 希望借助于本文阐述下个人的理解。
2.1 网络管理状态机
网络管理即协调网络中的ECU唤醒和睡眠的机制，如下为《AUTOSAR_SWS_CANNetworkManagement》定义的CANNM状态机，其包含如下几种工作模式：1)Bus Sleep Mode(睡眠模式BSM)在该模式下ECU通常进入深度睡眠，MCU的供电被断开，只保留唤醒源监测能力；2)Prepare Bus-Sleep Mode(预睡眠模式-PBM)节点从网络模式的准备睡眠阶段进入预睡眠模式，将缓存中未发送的应用报文发送，同时进行MCU下电前的准备，从而为进入深度睡眠预留时间；3)Ready Sleep State(准备睡眠模式-RSS)当节点不需要再请求网络（Network Request）时，需要进入RSS状态等待网络中其他网络管理节点也进入RSS状态，同时在该状态保持应用报文的收发状态； 4)Normal Operation State(常规运行状态-NOS)当节点从Repeat Message State超时跳出时，如果需要工作并主动维持网络，则进入NOS状态，并发送网络管理报文进行网路请求；5)Repeat Message State(重复报文状态-RMS)当节点从其他模式进入Network Mode时，默认先进入Repeat Message State，同时如果是自己主动唤醒则需要进入网络管理报文快发模式（NM Immediate Transmit State），从而能够快速启动网络，如果ECU是被动唤醒，则需要Repeat Message State中的正常周期发送模式（NM Normal Transmit State）。2.2 网络管理报文
上述网络管理状态机中各状态的切换需要以总线上的网络管理报文为依据，各节点通过发送及接收网络管理报文进行唤醒及网络维持，在《AUTOSAR_SWS_CANNetworkManagement》中网络管理报文的基本格式进行了规定，如下Byte0定义网络管理节点的源地址，在J1939网络中可以和ECU的源地址SA一致，Byte1定义为控制位向量CBV，来表征发送节点的状态，Byte2-Byte7预留给OEM进行自定义，OEM可定义ECU的唤醒原因、保持唤醒原因等，从而便于网络管理异常问题的排查等。Bit0:Repeat Message Request- 0x0：Repeat message state no request
- 0x1：Repeat message state requested
Bit3: NM Coordinator Sleep Ready Bit- 0x0：Start of synchronized shutdown is not requested by main
- 0x1：Start of synchronized shutdown is requested by main coordinator
Bit4:Active Wakeup Bit（该Bit位的作用我们在下面介绍） - 0x0：Node has not woken up the network(Passive wakeup)
- 0x1：Node has woken up the network(active wakeup)
Bit6:Partial Network Information(PNI)（局部网络管理使用）- 0x0：NM PDU Contains no Partial Network Request Information
- 0x1：NM PDU contains Partial Network Request Information
车辆在使用过程中，需要进行上电及下电，下电后车上大部分的部件及ECU电源会通过继电器或MOS等从蓄电池断开（通常由BCM来控制），从而降低整车静态放置的功耗。然而随着目前车辆功能的不断增多，比如PEPS、蓝牙钥匙、远程APP控车、迎宾等功能，通常是在车辆下电静态放置时使用，那这些功能相关的控制器是否都应该一直供电呢？通常这些控制器会连接蓄电池常电，但是在车辆下电静态放置时（KL15断开）其进入深度睡眠的低功耗状态，MCU的外设会关闭，MCU也会停止工作，只有SBC/CAN收发器监控车辆的唤醒行为并为MCU供电。 在下电KL15断开ECU已经睡眠后，如果车辆有功能需求，比如驾驶员携带蓝牙钥匙靠近车辆，蓝牙模块在监测到合法钥匙靠近后会激活迎宾灯光，那参与这个功能的BLE（蓝牙主模块）、BCM（车身控制器）、HCM（灯光控制器）等都需要正常工作，那这些ECU如何才能从睡眠状态唤醒并工作呢，有两种方式：用户在携带蓝牙钥匙靠近车辆后，BLE主模块在监测到合法钥匙后，通过激活线将BCM和HCM唤醒，从而让ECU从睡眠状态进入正常工作状态用户携带钥匙靠近车辆后，BLE主模块监测到合法钥匙后，通过发送网络管理报文唤醒BCM、HCM，BCM/HCM识别到网络管理报文后从睡眠状态进入正常工作状态。虽然上述方式都可以唤醒ECU，但是方式1存在一个重要的问题，上面只是迎宾灯光一个功能，但是车辆在下电后需要激活的功能还有很多，比如远控车窗、远程空调、车辆充电、远程查看车辆状态（胎压、电量）、靠近解锁、远离闭锁、智能补电等，如果都通过激活线来控制ECU休眠和唤醒，那整车的激活线将是错综复杂的（如图5），因此需要在不同的功能场景主动唤醒ECU通过发送网络管理报文把相关的ECU唤醒，从而参与到功能实现活动中，并在无网络需求时释放网络，通过网络管理的机制协调整车各ECU的唤醒及睡眠，只需要通过连接各ECU的总线网路可实现，而无需增加纷繁复杂的激活线。 4.1 第一步：设计整车的电源模式PowerMode
根据用户使用使用车辆的不同阶段，定义车辆的电源模式，在不同的电源模式下通过控制继电器或者eFuse（采用智能配电）给不同的设备供电，从而保证不同模式下功能的可用。4.2 第二步：制定功能到电源模式的Mapping表
4.3 第三步：制定功能到ECU的Mapping表
这一步即在项目的前期制定功能打点表，依据功能逻辑架构及功能分配方案进行功能到ECU的打点：
4.4 第四步：进行ECU 到电源模式的打点
有了第2步功能到电源模式的Mapping表，以及第3步功能到ECU的Mapping表，即可制定ECU到电源模式的Mapping表，此表可基于ECU List添加电源模式相关的列即可实现。图9：ECU到电源模式PowerMode的Mapping4.5 第五步：为不同的ECU分配不同的供电终端及唤醒终端
- 第一类：需要在Abandoned模式(车辆)下工作的ECU（如BCM、PEPS等）；
- 第二类：因为工作电流太大不能放在其他供电终端下（如EPS、FAN等），此时其主供电可以接KL30，但是其唤醒终端仍要与Mapping的电源模式相对应；
除了上面第二类ECU，第一类接蓄电池常电的ECU通常的唤醒方式即通过网络管理唤醒，由此可确定整车网络拓扑中需要参与网络管理的节点。5.1 唤醒源设置
首先要根据4.2章节整车Abandoned模式下不同功能场景，梳理ECU的唤醒源，例如对于某ECU节点，从功能场景触发分析其主要的唤醒源有KL15、RTC唤醒及网络管理报文唤醒等；在硬件设计上通常会将ECU自身的本地唤醒源接SBC，当有唤醒输入时SBC即可通过SW等输出MCU需要的VDD及其他如ADC_Ref电源。对于网络管理报文唤醒，需要CAN的收发器支持报文唤醒功能，常见的带唤醒的收发器有TJA1043 、TJA1145，而TJA1043不支持特定帧唤醒，而TJA1145则可以通过SPI配置特定帧唤醒和PNC功能；因而对于CAN唤醒而言也分为两种：一种是经过收发器验证后就是给定的ID和数据唤醒的(validated)，一种是不确定的待确认是不是接收到唤醒帧从而导致唤醒的(pending)。对于CAN Trcv而言，不管是TJA1145 还是TJA1043都需要支持唤醒源设置，并配置唤醒源，如下图所示为TJA1145的CANTrcv配置界面![]()
5.2 AUTOSAR NM协议栈如何实现唤醒和休眠
如下为AUTOSAR协议栈中NM相关模块，包括CANTrcv、CANIf、CANNM、NM、ComM等。5.2.1 上电过程
上电后CanTrcv初始化时判断之前使能了CAN唤醒且此时收发器的寄存器中的CAN唤醒位是置位的，则调用EcuM_SetEvent通知到EcuM此时有唤醒信号，EcuM模块调用ComM_EcuM_WakeUpIndication通知到ComM模块，随后ComM将对应通道置为COMM_FULL_COMMUNICATION模式，并协调Nm和CanNm模块进入对应模式。5.2.2 下电过程
下电条件的判断可以通过BswM模块或者手写代码当满足一定条件时调用EcuM提供的函数(如EcuM_GoDown），再通过EcuM模块完成下电流程。对于Full模式而言，当控制器需要下电时，就调用ComM的ComM_RequestComMode函数将其置为COMM_NO_COMMUNICATION模式即可，随后ComM会调用Nm模块、CanSM模块和Dcm模块，分别实现Nm进入Sleep、整个通道的通信关闭及关闭Dcm的接收功能.另外，在下电前EcuM模块需要调用EcuM_EnableWakeupSources(需要用户实现，可以调用CanIf_SetTrcvWakeupMode实现休眠前的CAN唤醒报文的一些设置)。对于Passive模式而言，当接收不到网络管理报文时(timeout)，CanNm首先进入Prepare Bus-Sleep Mode状态,此时CanNm通过Nm模块的用户回调(NmStateChangeIndCallback)告知到用户，可在用户函数中调用CanSM_RequestComMode函数设置相应通道的模式为NO_COMMUNICATION。和Full模式一样，下电前需要设置唤醒源。![]()
如上图所示的拓扑具有以下协调方法。GW 1已经将网络1和网络2上的信道配置为主动协调信道，GW 2连接网络2的信道配置为被动协调信道，但是连接网络3的信道配置为主动协调信道，GW 3连接网络3的信道被配置为被动协调信道，其连接到网络4的信道，是主动协调信道。当参数NmCoordinatorSyncSupport设置为TRUE时，协调嵌套自总线的功能可用。参数NmActiveCoordinator表明NM协调器是否在此通道上以主动方式协调器（主动协调通道）NmActiveCoordinator = TRUE，或以被动方式协调（被动通道）NmActiveCoordinator = FALSE。在其被动协调的信道上，仅当节点具有未决的网络管理请求或者由Nm协调器主动协调连接的网络没有准备好睡眠时，NM协调器才发送NM消息。这防止了在同一信道的2个NM协调器在它们准备睡眠时发送NM消息，并因此保持总线唤醒。如果没有这种机制，就不可能检测是否有至少一个其他节点是活动的。NM协调器在其主动协调通道上，应通过Nm_SetSleepReadyBit将NM消息中的NMcoordinatorSleepReady位设置为值1，当NM协调集群的所有节点准备睡眠（RemoteSleepIndication），且当NmSynchronizingNetwork使能，相应通道上收到一个Nm_SynchronizationPoint()调用，NM协调集群的所有通道配置为NmActiveCoordinator == TRUE，且NmBusType配置不为NM_BUSNM_LOCALNM。包含被动协调信道的节点不需要同步点，因为它们已经被它们的主动协调器的睡眠就绪位同步。如果被动协调通道上接收到Nm_CoordReadyToSleepIndication，则NmCoordinator应在其所有主动协调通道上通过API调用Nm_SetSleepReadyBit，将NMCoordinatorSleepReady位设置为SET(1)。 如果被动协调通道上接收到Nm_CoordReadyToSleepCancellation，则NmCoordinator应在其所有主动协调通道上通过API调用Nm_SetSleepReadyBit，将NMCoordinatorSleepReady位设置为UNSET(0)。即NM协调器在其被动协调通道上不设置睡眠就绪位，但转发其从被动协调通道上收到的睡眠就绪位的状态的改变到它的主动协调通道上。在NM协调器的主动协调信道上，不调用Nm_CoordReadyToSleepIndication和NM_CoordReadyToSleepCancellation。在睡眠就绪位被请求SET（1）后，NM协调器应开始协调关机。NmGlobalCoordinatorTime应至少设置为关闭所有协调网络所需的最大时间。这包括所有嵌套连接。如下图所示： 当协调关闭因任何原因被中断，NM协调器应在其主动协调通道上通过API调用Nm_SetSleepReadyBit将NMCoordinatorSleepReady设置位UNSET（0)。AUTOSAR网络管理通过成熟的机制协调网络上ECU的睡眠和唤醒，对于OEM来说需要从整车层级功能出发制定网络拓扑中参与网络管理的节点，同时制定网络管理的规范，明确状态机中各时间参数以及通信矩阵中NM报文从而输入给Tier1进行开发，在零部件开发层级供应商可通过AUOTSAR工具配置网络管理相关模块，如CANNM、NM等，并通过集成编译实现网络管理的功能。以上是我对AUTOSAR NM的浅显理解，不免会有错误，请各位同行指正。 -end-
