CAN J1939 设备在通信超时后停止响应
CAN J1939 device stops responding after communication timeout
我是一个更高层次的人，我没有也不想了解太多 can-bus, j1939 甚至特定的 ECU。我只是不喜欢软件解决方案，所以我想问一下，客户的要求是否合法。
- 如果特定 ECU 在加电后 300 毫秒超时内未接收到 CAN 帧，它将停止响应任何进一步的帧，并且必须重新启动。这是客户技术人员的信息，我只好相信了。
- 可以在 CAN 驱动程序线程准备好后给 ECU 上电，但最终客户需要进行一些额外的布线。
- 软件解决方案都不好或更糟，比如 运行 FreeRTOS 在重要检查之前，将 CAN 驱动程序代码放到与其他产品通用的代码中，或者在引导加载程序中启动 CAN 外设而留下 运行 没有软件控制，直到驱动程序启动。
- 敏感的地方是，我们在规范中没有明确要求在这么短的时间内启动CAN驱动程序。客户说，它是 J1939 规范的一部分。
有人可以证实或反驳 J1939 允许设备在静默 300 毫秒后不可恢复地停止接收或要求设备在通电后 300 毫秒内开始传输吗？或者至少指导我了解 J1939 标准的部分内容，这可能会考虑到这一点？
谢谢
If particular ECU doesn't receive CAN frame within 300 ms timeout after powerup, it stops responding to any further frames and must be power cycled. This is a information from customer's technicians, I have to just believe it.
这当然完全取决于它正在执行的任务。
通常，ECU，如 car/truck 中的汽车计算机等，永远不允许挂起 up/latch。正常的操作过程是让 ECU reboot/reset 自身或恢复到故障安全模式。
但是对于拖拉机和重型机械，正常的安全模式是“停止一切”。
It is possible to powerup ECU after CAN driver thread is ready, but it would require some extra wiring by end customers.
我不知道这是什么意思。什么是“额外布线”？有什么东西可以在一个节点重启时让其他节点保持普通模式？终端电阻？一些肮脏的上电延迟电路？
Software solutions are all bad or worse, like running FreeRTOS before important checks, put CAN driver code to code common with other products, or start CAN periphery in the bootloader and left running without software control until driver starts.
一般来说，习惯上很早就初始化关键硬件，如时钟、看门狗、预分频器、拉电阻等。初始化硬件外围设备可能很重要，也可能不重要。通常在执行 CRT 之后，在 main() 开始时执行此操作，并且初始化顺序通常很重要。
如果从上电复位到 main() 启动的延迟超过 300 毫秒，则程序有严重错误。
The sensitive part is, that we have no explicit demand to start CAN driver within such a short time in specification. Customer says, that it's part of J1939 specification.
我用 J1939 的工作不多，我不记得它具体说了什么，但 300 毫秒在实时系统中是永恒的！这不是“短时间”。
一般来说，正确设计的 mission-/safety-critical CAN 控制系统在 automotive/industrial 设置中的工作方式如下：
- 所有数据都以固定的时间间隔重复发送，无论是否发生变化。通常每 10 毫秒一次或每 100 毫秒一次。
- 没有收到新数据的节点暂时使用之前收到的数据。
- 从接收到最后一个有效数据时开始超时，此时接收节点必须停止使用旧数据并恢复到故障安全模式。这个时间通常与受控对象移动的速度有关。在 100 毫秒的倍数后超时是很常见的。
我想说你们客户的要求很合理，没什么特别的。
同事回答，没有这个需求，只有模糊的300ms timeout。
我是一个更高层次的人，我没有也不想了解太多 can-bus, j1939 甚至特定的 ECU。我只是不喜欢软件解决方案，所以我想问一下，客户的要求是否合法。
- 如果特定 ECU 在加电后 300 毫秒超时内未接收到 CAN 帧，它将停止响应任何进一步的帧，并且必须重新启动。这是客户技术人员的信息，我只好相信了。
- 可以在 CAN 驱动程序线程准备好后给 ECU 上电，但最终客户需要进行一些额外的布线。
- 软件解决方案都不好或更糟，比如 运行 FreeRTOS 在重要检查之前，将 CAN 驱动程序代码放到与其他产品通用的代码中，或者在引导加载程序中启动 CAN 外设而留下 运行 没有软件控制，直到驱动程序启动。
- 敏感的地方是，我们在规范中没有明确要求在这么短的时间内启动CAN驱动程序。客户说，它是 J1939 规范的一部分。
有人可以证实或反驳 J1939 允许设备在静默 300 毫秒后不可恢复地停止接收或要求设备在通电后 300 毫秒内开始传输吗？或者至少指导我了解 J1939 标准的部分内容，这可能会考虑到这一点？
谢谢
If particular ECU doesn't receive CAN frame within 300 ms timeout after powerup, it stops responding to any further frames and must be power cycled. This is a information from customer's technicians, I have to just believe it.
这当然完全取决于它正在执行的任务。
通常，ECU，如 car/truck 中的汽车计算机等，永远不允许挂起 up/latch。正常的操作过程是让 ECU reboot/reset 自身或恢复到故障安全模式。
但是对于拖拉机和重型机械，正常的安全模式是“停止一切”。
It is possible to powerup ECU after CAN driver thread is ready, but it would require some extra wiring by end customers.
我不知道这是什么意思。什么是“额外布线”？有什么东西可以在一个节点重启时让其他节点保持普通模式？终端电阻？一些肮脏的上电延迟电路？
Software solutions are all bad or worse, like running FreeRTOS before important checks, put CAN driver code to code common with other products, or start CAN periphery in the bootloader and left running without software control until driver starts.
一般来说，习惯上很早就初始化关键硬件，如时钟、看门狗、预分频器、拉电阻等。初始化硬件外围设备可能很重要，也可能不重要。通常在执行 CRT 之后，在 main() 开始时执行此操作，并且初始化顺序通常很重要。
如果从上电复位到 main() 启动的延迟超过 300 毫秒，则程序有严重错误。
The sensitive part is, that we have no explicit demand to start CAN driver within such a short time in specification. Customer says, that it's part of J1939 specification.
我用 J1939 的工作不多，我不记得它具体说了什么，但 300 毫秒在实时系统中是永恒的！这不是“短时间”。
一般来说，正确设计的 mission-/safety-critical CAN 控制系统在 automotive/industrial 设置中的工作方式如下：
- 所有数据都以固定的时间间隔重复发送，无论是否发生变化。通常每 10 毫秒一次或每 100 毫秒一次。
- 没有收到新数据的节点暂时使用之前收到的数据。
- 从接收到最后一个有效数据时开始超时，此时接收节点必须停止使用旧数据并恢复到故障安全模式。这个时间通常与受控对象移动的速度有关。在 100 毫秒的倍数后超时是很常见的。
我想说你们客户的要求很合理，没什么特别的。
同事回答，没有这个需求，只有模糊的300ms timeout。