Passive Autosar Nm设计

定义

网络类型是Passive的，网络管理是passive autosar nm。表现为不发送Nm报文，只接收Nm报文。

相关知识

唤醒源

主动唤醒源：承担着主动唤醒网络责任的唤醒源，称为主动唤醒源。比如：

1. KL15硬线：通过KL15硬线唤醒网络，说明当前网络没有节点参与通信，为了快速将网络唤醒，建立通信功能，被KL15硬线唤醒的节点，需要主动地去唤醒网络，进而将网络上其他节点唤醒。类似的其他硬线唤醒方式，或定时器唤醒，也可以看作主动唤醒源；
2. User请求：User请求，是指通过 ComM_RequestComMode 接口请求通信的方式，发起点为SWC，由于功能需要，节点需要在某些工况下主动拉起其他节点通信；
3. ERA信号：ERA信号的使用，说明当前节点有多个物理Channel，PNC信息需要在不同的Channel之间路由，以实现不同网络唤醒的目的。

被动唤醒源：不需要承担唤醒网络责任的唤醒源，称为被动唤醒源。比如：收到NM Msg。

1. 网络管理没有PN功能：节点收到的网络管理报文没有PNC信息，此时网络管理报文看作被动唤醒源。
2. 网络管理具有PN功能：如果对应的ECU充当Gateway角色，且有多个物理Channel，PNC关联多个Channel，网络管理报文可看作主动唤醒源（前面提到的ERA信号）；如果PNC 仅关联本Channel，不需要路由，网络管理报文看作被动唤醒源。

网络主动唤醒：由主动唤醒源触发，调用 CanNm_NetworkRequest 接口唤醒网络的方式。

网络被动唤醒：由被动唤醒源触发，调用 CanNm_PassiveStartUp 接口唤醒网络的方式。

网络和通信状态

ECU上电，CanNM初始化完后，CanNM处于Bus-Sleep Mode，通信处于released状态。

• 如果网络类型是Passive的，则不会外发网络管理报文，调用 CanNm_PassiveStartup，CanNM状态机进入Repeat Message State，此时可以发送应用报文，但通信状态依然是released，所以之后进入Ready Sleep State。

• 如果网络类型不是Passive的，通过调用 CanNm_NetworkRequest进入Repeat Message State，此时既可以发送网络管理报文，也可以发送应用报文，之后进入Normal Operation State。

• 如果某节点想要主动请求网络通信，则该节点需要有主动外发网络管理报文的能力，这样才有唤醒其他节点的可能。这也意味着此节点对应ECU的网络类型不能是Passive的。

通信状态

网络通信的requested/released。需要调用接口CanNm_NetworkRequest / CanNm_NetworkRelease进行切换。

• CanNm_PassiveStartUp：只负责CanNM状态机的切换，即：由Bus-Sleep Mode/Prepare Bus-Sleep Mode切换到Network Mode::Repeat Message State。

• CanNm_NetworkRequest：不仅负责CanNM状态机的切换，还负责节点通信状态的切换。

ECU 上下电

ECU如何上电？

一些ECU对静态电流有要求，因此要求是断电系统，硬件上BAT（KL30）给收发器常供电，当CAN总线上有数据时，或者有其他唤醒事件发生时，INH引脚被拉高，3V3和5V电源芯片使能，进而给主芯片/收发器供电，当主芯片供电以后，程序开始运行，但此时网络处于Bus Sleep Mode，ECU并不能立马外发报文，需要对唤醒事件进行有效性验证，避免因总线抖动或者其他干扰造成的ECU无效唤醒。

eg：收发器在handler中检查唤醒源，判断到上电或者CAN总线干扰事件时，会通知EcuM有唤醒事件，EcuM通过CanIf模块调用 CanTrcv_CheckWakeup检查唤醒源。如果EcuM使能了唤醒源的检查，则EcuM调用 EcuM_StartWakeupSources接口，使得Controller进入Start状态，至此，ECU具备了收发报文的能力。

ECU如何下电？

当ECU需要下电的时候，即需要切断Vcc时，会通过SPI给收发器发送进入Sleep Mode的指令，如果收发器在Sleep Mode，INH Pin脚会处于高阻状态，此时与收发器连接的电源芯片禁能，即无法给主芯片提供Vcc电，也无法给收发器提供Vcc和Vio电。所以主芯片会完全的断电，实现了最大程度的节能。

唤醒源的Check、Set和Valid

对唤醒源的操作，一般需要经过Check、Set、Valid三步。

如何Check唤醒事件

控制器和收发器可以使用中断或轮询来检测唤醒事件，当有Can Bus的唤醒事件时，EcuM分不清楚是谁发现的，通过 EcuM_CheckWakeup 一查，是控制器还是收发器，EcuM就清楚了。实际还是依靠CanIf，确定是Controller还是Trcv。

• 中断方式Check唤醒事件：外部中断唤醒事件到来时，可以是Controller中断，也可以是Transceiver中断。中断例程中主动调用EcuM的 EcuM_CheckWakeup

• 轮询方式Check唤醒事件：EcuM在自己的Task，调用 EcuM_CheckWakeup

不管轮询还是中断方式，谁发现了唤醒事件，谁有责任告诉EcuM，即调用EcuM_CheckWakeup

注意： EcuM_CheckWakeup这个接口属于Autosar的Callout函数，此函数的实现由User定义。

Set唤醒源

唤醒事件既可以使用Trcv检查，也可以使用Controller检查。假设用Trcv中断方式检查唤醒事件，当Trcv接收到一帧报文时，与Controller相连的Rx Pin拉低，触发中断(设置下降沿或者双边沿触发)，之后进入ICU中断处理程序。

通过上图，可以看出，Trcv通过调用 EcuM_SetWakeupEvent 接口告知EcuM，是谁唤醒ECU。Set的主要目的是把唤醒事件挂起，以便EcuM (EcuM_MainFunction )后续检查唤醒事件的有效性。

/* #34 Add this source to the global pending wakeups variable. */
EcuM_PendingWakeups |= WakeupSourc

如何Validate唤醒事件

如果想进一步的分析唤醒事件是不是有效的总线唤醒源（比如：网络管理报文），需要ECU有正常的收发报文能力，想要收发报文，Transceiver和Controller两个模块均需要启动。

所以，在验证唤醒事件之前，需要将Trcv和Controller切换到工作模式，通过EcuM_StartWakeupSources 即可完成，会进一步调用 CanSM_StartWakeupSources接口。CanSM_StartWakeupSources 会调用 CanIf_SetControllerMode ，让Controller进入Started Mode。

和Check一样，谁发现谁验证。下图以WakeupSource==CanIf说明

如果唤醒事件有效，EcuM需要：

• 通知ComM唤醒事件有效，通过 ComM_EcuM_WakeUpIndication

• 通知BswM唤醒事件有效，如果BswM还没有初始化，EcuM将信息通过一个全局变量缓存。如果EcuM状态大于ECUM_STATE_STARTUP_TWO，则调用BswM_EcuM_CurrentWakeUp

如果唤醒事件无效：

• EcuM通知BswM，执行对应的ActionList

• 一般来说，会在EcuM模块配置两个时间参数，CheckWakeup和ValidateWakeup时间，如果CheckWakeup时间走完，没有判断到有效的唤醒源，则调用EcuM_StopWakeupSources去关闭Trcv和Controller，之后Ecu失去通信能力。

Passive Wakeup过程

当没有User主动请求通信时，唤醒过程被认为是Passive Wakeup，比如：收到网络管理报文就属于Passive Wakeup过程，如果CanNM模块在Bus-Sleep Mode收到网络管理报文，会调用Nm_NetworkStartIndication通知NM模块，之后NM模块通过ComM_Nm_NetworkStartIndication 通知ComM。

注意：

不要和网络类型混淆，不管节点的网络类型是被动的还是主动的，都可以被动唤醒。被动网络节点被动唤醒不会外发网络管理报文，主动网络节点被动唤醒会外发网络管理报文。

注意：

ComM从 COMM_NO_COM_REQUEST_PENDING子状态想要进入COMM_FULL_COM_NETWORK_REQUESTED，需要满足两个条件：

1. 通信允许，即CommunicationAllowed = True。
2. CanSM请求COMM_FULL_COMMUNICATION

CommunicationAllowed = True，谁控制这个条件呢？

对于Flexible EcuM，条件由BswM调用 ComM_CommunicationAllowed控制。BswM是先模式仲裁，后执行对应的动作。模式仲裁请求包括：Requests和Indications。

前面提到有效的唤醒事件已确认，EcuM会调用 BswM_EcuM_CurrentWakeup 告知BswM(属于Indication)。同时，检查是否收到网络管理报文，如果这两个Rule满足，则允许通信，之后BswM执行对应的ActionList，其中就包括 ComM_CommunicationAllowed 的调用，即设置CommunicationAllowed = True。

谁请求COMM_FULL_COMMUNICATION？

在唤醒源验证有效时，EcuM调用 ComM_EcuM_WakeUpIndication，EcuM就请求了COMM_FULL_COMMUNICATION::COMM_FULL_COM_READY_SLEEP 状态。

然后ComM可以在 ComM_MainFunction中进行状态的切换，此时ComM会干两件事：

• 打开通信栈，即请求对应的CanSM模块进入FULL_COMMUNICATION状态，

CanSM_RequestComMode( Channel, COMM_FULL_COMMUNICATION );

• 切换网络状态，即调用接口 Nm_PassiveStartUp ，网络进入NetworkMode::RepeatMessageState

Passive NM配置

CanNm配置使能channel的passive mode：

ComM配置Nm类型为PASSIVE：

ComM配置No Com：

Nm配置使能channel的passive mode：

NmGlobal也配置passive mode。

唤醒源配置

收发器支持wakeup，增加CanTrcv模块，并关联上唤醒源，具体配置如下：

Dio定义收发器对于的port引脚。

CANIF增加容器，关联收发器，开启对收发器唤醒源的Check和Set相关配置。

CANSM关联收发器

唤醒源验证

这个配置参数用于控制CAN控制器在检测到唤醒事件时，是否仅通过接收网络管理（NM）消息来验证该事件。具体解释如下：

• 当设置为 true 时，只有接收到网络管理（NM）消息才会验证检测到的唤醒事件。这意味着只有在接收到特定的NM消息后，系统才会确认这是一个有效的唤醒事件。

• 当设置为 false 时，任何来自对应CAN控制器的消息都会验证检测到的唤醒事件。这意味着只要接收到任何消息，无论其类型如何，系统都会认为这是一个有效的唤醒事件。

启用唤醒源的验证

相关知识参加之前章节。

这里我们设置CheckWakeup和ValidateWakeup时间，就会启用唤醒源的验证。

Coding

1. 修改 EcuM_Callout_Stubs.c唤醒源验证相关接口如下：

2. 修改 EcuM_Callout_Stubs.c唤醒源check接口

收发器远程唤醒序列

如果抖动导致总线电平跳变，但没有形成有效CAN帧，收发器会将噪声过滤。

通过严格的时序和过滤机制，避免因总线噪声、强制拉低（Dominant Clamped）等导致的误唤醒事件。

TJA1043通过CAN总线实现远程唤醒的序列过滤逻辑总结如下：

1. 有效唤醒模式：需包含显性-隐性-显性三个阶段，各阶段持续时间分别至少为twake(busdom)、twake(busrec)、twake(busdom)，且整个模式需在tto(wake)bus时间内接收完成。

2. 唤醒事件无效情况：

   • 唤醒序列传输时TJA1043切换到正常模式。

   • 完整唤醒模式未在tto(wake)bus时间内接收完成。

   • 接收唤醒序列时检测到 VIO欠压(VIO < Vuvd (VIO))。

3. 内部逻辑重置：上述无效情况发生时，内部唤醒逻辑重置，需重新传输完整唤醒序列才能触发唤醒事件。

设计考虑点

这里列举一些和网络管理相关的，需要考虑的点或者说是checklist：

1. CAN网络相关的条件。比如：点火信号获取，NM睡眠状态获取，收发器的操作等，是否合理？

2. 异常电源状态的处理。比如：高低压，高低温时，是否要执行一些动作？

3. 特殊场景。比如：产线下线时，快速休眠，下电逻辑是否合理？

问题记录

现象：停发模拟的网络报文，ECU进入BusSleep后，MCU没有走下电流程，还在正常工作，再重新恢复模拟的网络报文，CAN工具会报错误帧，且无法恢复通信，需要ECU手动重启恢复。

原因：网络睡眠后，Ecu State状态机走到了shutdown状态，执行了BswM反初始化。此时，CAN控制器处于Sleep状态，收发器处于Standby状态。MCU电源管理不使用autosar提供的机制，还在正常工作中。由于BswM反初始化了， BswM_MainFunction不会再执行。即使后面发送报文，也执行了CanIf_CheckWakeup，唤醒事件通知不到BswM了，Ecu State状态机不会跳转，CAN控制器不会打开，所以收不到报文。

解决：网络睡眠一直维持PendingRequests即可，这样就不走autosar的Ecu State状态机，就不会shutdown了。然后，通知MCU Power模块，走内部的下电流程。

打赏