CAN J1939 设备在通信超时后停止响应

Question

我是一个更高层次的人，我不知道也不想知道很多关于can-bus、j1939 甚至特定 ECU 的信息。我只是不喜欢软件解决方案，所以我想问一下，客户的要求是否合法。

1. 如果特定 ECU 在通电后 300 毫秒超时内未接收到 CAN 帧，它将停止响应任何进一步的帧并且必须重新上电。这是客户技术人员提供的信息，我只能相信。
2. 可以在 CAN 驱动线程准备好后给 ECU 上电，但最终客户需要额外接线。
3. 软件解决方案都不好或更糟，例如在重要检查之前运行 FreeRTOS，将 CAN 驱动程序代码放入与其他产品通用的代码中，或者在引导加载程序中启动 CAN 外围设备并在没有软件控制的情况下继续运行，直到驱动程序启动。
4. 敏感的部分是，我们在规范中没有明确要求在如此短的时间内启动 CAN 驱动程序。客户说，这是 J1939 规范的一部分。

有人可以确认或反驳，J1939 允许设备在 300 毫秒静默后不可恢复地停止接收，或要求设备在通电后 300 毫秒内开始发送吗？或者至少引导我了解 J1939 标准的部分内容，这可能会考虑到这一点？

谢谢

Answer 1

如果特定 ECU 在通电后 300 毫秒超时内未接收到 CAN 帧，它将停止响应任何进一步的帧并且必须重新上电。这是客户技术人员提供的信息，我只好相信了。

这当然完全取决于它正在执行的任务。

一般来说，ECU，如汽车/卡车等中的车载计算机，绝不允许挂断/锁定。 ECU 的正常操作过程是重新启动/重置自身或恢复到故障安全模式。

但对于拖拉机和重型机械，正常的安全模式是“停止一切”。

可以在 CAN 驱动线程准备好后给 ECU 上电，但需要终端客户进行一些额外的接线。

我不知道这是什么意思。什么是“额外布线”？当一个节点重新启动时，有什么东西可以让其他节点保持在普通模式下？终端电阻？一些肮脏的上电延迟电路？

软件解决方案都不好或更糟，例如在重要检查之前运行 FreeRTOS，将 CAN 驱动程序代码放入与其他产品通用的代码中，或者在引导加载程序中启动 CAN 外围设备并在没有软件控制的情况下继续运行，直到驱动程序启动。

一般来说，很早就初始化时钟、看门狗、预分频器、拉电阻等关键硬件是一种习惯。初始化硬件外围设备可能很重要，也可能不重要。通常在 CRT 执行后，在 main() 开始时执行此操作，并且初始化的顺序通常很重要。

如果从上电复位到 main() 开始的延迟超过 300 毫秒，则程序有严重问题。

敏感的部分是，我们在规范中没有明确要求在如此短的时间内启动 CAN 驱动程序。客户说，这是 J1939 规范的一部分。

我对 J1939 的工作并不多，我不记得它具体说了什么，但 300 毫秒在实时系统中是永恒的！这不是一个“短时间”。

一般来说，在汽车/工业环境中正确设计的任务/安全关键型 CAN 控制系统的工作方式如下：

• 所有数据都以固定的时间间隔重复发送，无论它是否已更改。通常每 10 毫秒一次或每 100 毫秒一次。
• 尚未收到新数据的节点将暂时使用之前收到的数据。
• 从接收到最后一个有效数据的时间点开始存在超时，此时接收节点必须停止使用旧数据并恢复到故障安全模式。该时间通常与受控对象移动的速度有关。在 100 毫秒的倍数后出现超时是很常见的。

我会说你客户的要求很合理，没什么特别的。

Answer 2

我的同事回答，没有这样的需求，只是模糊的 300 毫秒超时。