Проверка отметок времени сообщений, отправленных по шине CAN - PullRequest
0 голосов
/ 08 января 2019

Для обеспечения свежести сообщения в CAN-шине к сообщению может быть добавлена ​​временная метка. Затем получатель может проверить временную метку (может быть усечена) и сравнить ее со своим собственным локальным таймером, чтобы решить, хочет ли он продолжить сообщение.

Мой вопрос: какое решение использует получатель (на практике), чтобы проверить временную метку на свежесть? Кажется, что просто смотреть на абсолютное значение разницы не идеально, поскольку длительность отправки сообщения по шине CAN не является постоянной (обработка коллизий / арбитраж по шине).

1 Ответ

0 голосов
/ 09 января 2019

Решение о "свежести" сообщения является чисто специфической логикой прикладного уровня, и, следовательно, решение не является стандартным протоколом. Это сильно зависит от сценариев использования, в которых участвует Приложение. Например, ADAS может потребоваться от данных пакета объекта радара со свежестью 20 мс, например.

TimeSync протокол является одним из вспомогательных механизмов, используемых для обеспечения высокоточной связи чувствительных ко времени узлов.

В TimeSync локальные часы подчиненных узлов настраиваются на часы ведущего. Посредством сообщений SYNC + FUP также учитывается длительность отправки сообщения от триггера на обнаружение ACK на шине.

Обеспечивая общие часы между узлами, практически сообщения так же свежи, как и приходят.

Примечание. Время отклика CAN для сообщения в канале 1 МБод составляет не более 300 мкс, и в зависимости от применяемой архитектуры ПО от приема приемопередатчика до приложения не должно пройти больше 5-10 мкс.

...