0

设想

有一个基于 Linux 的设备连接到 CAN 总线。设备定期发送 CAN 报文。该消息携带的数据的性质类似于测量而不是命令，即只有最近的一个实际上是有效的，如果某些消息丢失了，只要最近的一个成功接收就没有问题。

然后，有问题的设备与 CAN 总线断开连接的时间比后续消息传输之间的间隔长得多。设备逻辑仍在尝试传输消息，但由于总线断开，CAN 控制器无法传输任何消息，因此消息正在累积在 TX 队列中。

一段时间后，CAN 总线连接恢复，所有积累的消息都被一一踢到总线上。

问题

  1. 当 CAN 总线连接恢复时，将从 TX 队列中传输未定义数量的过时消息。
  2. 当 CAN 总线连接仍然不可用但 TX 队列已满时，一些最近的消息（即唯一有效的消息）的传输将被丢弃。
  3. 一旦 CAN 总线连接恢复，在刷新 TX 队列时会出现短期流量突发。如果使用了时间触发总线调度（在我的情况下），这可以改变时间触发总线调度。

问题

我的应用程序使用 SocketCAN 驱动程序，所以基本上这个问题应该适用于 SocketCAN，但如果有的话，也会考虑其他选项。

我看到了两种可能的解决方案：定义消息传输超时（如果在某个预定义的时间内没有传输消息，它将自动丢弃），或者手动中止过时消息的传输（尽管我怀疑使用套接字根本不可能API）。

由于第一个选项对我来说似乎是最真实的，所以问题是：

  1. Linux下如何定义CAN接口的TX超时？
  2. 除了 TX 超时之外，是否存在其他选项来解决上述问题？
4

1 回答 1

-2

我不知道 SocketCAN 的内部原理，但我认为问题的大部分应该在更一般、更合乎逻辑的层面上解决。

之前，有一个方面需要澄清：问题包括标签...

  • 如果 CAN 通信与实现安全功能无关，您可以选择任何您认为有用的解决方案。在这种情况下，第二个替代方案的某些部分也可能对您有用，但这些不是强制性的。

  • 但是，如果在与安全相关的环境中使用通信，则必须有一个概念来考虑 IEC 61508（一般可​​编程电子系统的安全）和 IEC 61784-x/62280（安全通信协议）的要求. 这些标准通常会导致一些对任何嵌入式通信都派上用场的协议措施，尤其是对于目前的问题：

    • 将序列计数器添加到协议帧。接收器应监控它看到的计数器值不会比允许的“跳跃”更大（例如，如果您允许沿途错过 2 帧，则最大计数器增量可能是 +3。CAN 总线可能会使帧加倍，因此也必须容忍 +0 的计数器增量。
    • 接收器必须监视在超时期间内每个接收到的帧都跟随着另一个。如果您的 CAN 连接在此期间丢失并恢复，则取决于中断时间更长还是在超时范围内。此外，接收器可能会过早监测到帧没有跟随前一个帧，但如果帧包含正确的数据，这通常是没有必要的。

    • [...] 该消息携带的数据的性质类似于测量而不是命令，即只有最近的消息实际上是有效的，如果某些消息丢失，只要收到最新的消息就不是问题成功地。

      通过CAN，您永远不会传达“命令”，即每个命令都可以触发更改，例如“切换输出状态”或“将设定值增加一个单位”，因为您永远不知道帧重复是否击中您.

      此外，您决不能通过单个帧传达“任何与安全相关的内容”，因为任何帧都可能因错误而丢失或损坏。相反，“命令”应作为具有测量或设定值更新的周期性帧流传输（如测量）。

现在，为了从协议设计中获得所需的可用性，TX 队列不应该很长。如果你真的觉得你需要那个队列，那么与它面临的时序要求相比，它可能是总线过载了。从我的角度来看，TX“队列”不应该长于一两帧。然后，恢复CAN连接的问题就基本解决了……

于 2020-04-17T15:09:58.453 回答