Обнаружение потери связи CAN

Есть две совершенно разные вещи, которые следует учитывать:

1. На прикладном уровне отвечает ли тот, с кем вы общаетесь, вовремя и отправляет ли он достоверные данные?
2. Имеются ли аппаратные ошибки на шине CAN?

Относительно 2), кадры ошибок bus-off и CAN являются аппаратными ошибками, обычно вызванными довольно серьезными вещами, такими как неправильная установка, короткое замыкание между высоким/низким уровнем CAN, плохими проводами/разъемами, помехами EMI, плохим/отсутствующим завершением, дрянным заземлением сигнала и /или щит и т. д. В основном это неисправимые ошибки, с которыми программа мало что может сделать. Единственное, что вы можете сделать, это отобразить некоторую диагностику.

Вместо того, чтобы возиться и исследовать различные ошибки CAN-шины, этот тип надежной прошивки (предполагая, что это промышленность/автомобилестроение) должен быть разработан таким образом, чтобы он просто проверял, получили ли вы правильные данные вовремя, как того требует пункт 1). Потому что это единственное, что имеет отношение к вам. Если шина чувствует себя плохо, если есть кадры с ошибками, но вы все еще получаете данные - хорошо, просто продолжайте работать, пока можете.

Таким образом, единственное, что представляет интерес, — это использовать таймер с разумным тайм-аутом — в зависимости от того, насколько быстро движется управляемая машина (500 мс — это общеотраслевой стандарт, хотя более быстрым машинам может потребоваться более короткий тайм-аут). Каждый раз, когда вы получаете действительный (серию) пакетов CAN, вы обновляете этот таймер. Когда таймер истечет, вернитесь в безопасное состояние.

Когда и как восстанавливаться из безопасного состояния, сильно зависит от приложения. Многие критически важные для безопасности приложения запрещают восстановление после критической ошибки без явной команды оператора.