通信超时后，J1939设备是否停止响应？

Question

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

1. 如果特定的ECU没有接收到可以在powerup之后的300 ms超时内帧，它将停止对任何其他帧的响应，并且必须是功率循环。这是客户技术人员提供的信息，我不得不相信。
2. 在CAN驱动线程准备好之后，powerup ECU是可能的，但是它需要一些终端客户的额外连接。
3. 软件解决方案都是坏的或更糟的，比如在重要检查之前运行FreeRTOS，将CAN驱动程序代码放入与其他产品相同的代码，或者在引导加载程序中启动CAN外围，直到驱动程序启动时才运行。
4. 敏感的部分是，我们没有明确的需求启动可以在如此短的时间内驱动规格。客户说，这是J1939规范的一部分。

有人能否确认或反驳，J1939允许设备在沉默300 ms后无法恢复接收，或者要求设备在powerup之后在300 ms内开始传输？或者至少引导我了解J1939标准的某些部分，哪个可能会这样认为呢？

谢谢

Answer 1

我的同事回答说，没有这样的要求，只有300毫秒的暂停。

Answer 2

如果特定的ECU没有接收到可以在powerup之后的300 ms超时内帧，它将停止对任何其他帧的响应，并且必须是功率循环。这是客户技术人员提供的信息，我不得不相信。

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

通常，ECU，如汽车/卡车等汽车计算机中的ECU，永远不允许挂断/闩锁。正常的操作过程是ECU要么重新启动/重置自身，要么恢复到故障安全模式。

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

在CAN驱动线程准备好之后，powerup ECU是可能的，但是它需要一些终端客户的额外连接。

我不知道这是什么意思。什么是“额外布线”？让其他节点在重新启动时处于公共模式的东西？终端电阻器？一些肮脏的加电延迟电路？

软件解决方案都是坏的或更糟的，比如在重要检查之前运行FreeRTOS，将CAN驱动程序代码放入与其他产品相同的代码，或者在引导加载程序中启动CAN外围，直到驱动程序启动时才运行。

一般来说，它的习惯是初始化关键的硬件，如时钟，看门狗，预分频器，拉电阻器等。初始化硬件外围设备可能是关键，也可能不是关键。在执行CRT之后，在main()的开头执行这个操作是定制的，初始化的顺序通常非常重要。

如果从电源复位到main()的启动有超过300 is的延迟，那么程序就出现了严重的问题。

敏感的部分是，我们没有明确的需求启动可以在如此短的时间内驱动规格。客户说，这是J1939规范的一部分。

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

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

• 所有数据都在固定的时间间隔内重复发送，无论数据是否已更改。通常每10毫秒或每100毫秒一次。
• 没有接收到新数据的节点现在将使用先前接收的数据。
• 从何时收到最后有效数据，当接收节点必须停止使用旧数据并恢复到故障安全模式时，就会出现超时。这一次通常与被控对象的移动速度有关。在100‘s的倍数之后有超时是很常见的。

我想说，你的客户的要求是非常合理的，这不是什么不寻常的。