¿Requisito adicional para la suma de comprobación sobre el bus CAN?

Es un juego de probabilidad y una compensación de costos. ¿Cuál es el costo de obtener datos erróneos? ¿Cuál es el costo de disminuir la posibilidad de obtener datos erróneos?

Nunca se puede garantizar absolutamente que los datos se reciban correctamente. Todo lo que puedes hacer es disminuir la posibilidad de que eso suceda al lanzar cada vez más recursos. En algún momento, no vale la pena gastar más recursos para reducir un poco más la posibilidad de que los datos sean malos. Solo tú puedes responder cuál es ese punto.

Dicho esto, la suma de comprobación CRC de 15 bits que CAN puede usar en cada mensaje es lo suficientemente buena para la gran mayoría de las aplicaciones. Los CRC pueden organizarse para detectar siempre un solo error de bit, pero es posible cambiar varios bits para que el resultado se vea correcto.

El CRC de 15 bits en un mensaje CAN tiene 32768 valores posibles. Si le arrojas contenido de mensajes aleatorios, hay una posibilidad en 32768 de lo que resulta en cualquier CRC en particular. A primera vista, por lo tanto, puede decir que la probabilidad de que un mensaje defectuoso parezca correcto es la probabilidad de que se produzcan dos o más errores de bit dentro de un mensaje, dividido por 32768. En realidad, es menor que eso, ya que algunos errores aleatorios harán que todo el mensaje CAN sea estructuralmente incorrecto, pero lo anterior es un buen comienzo.

Calcula la probabilidad de obtener bits malos en primer lugar a partir de la tasa de errores de bits. El bus CAN típico se implementa como una señal diferencial simétrica, y es bastante robusto incluso con mucho ruido externo. Tenga en cuenta que CAN fue diseñado originalmente para automóviles, que son entornos muy ruidosos eléctricamente. El punto de esto es que la tasa de error de bits será bastante pequeña. Por ejemplo, 1 en 10 ⁶ sería una tasa de error de bits enorme e improbable.

A menos que esté haciendo algo muy inusual y crítico, solo usar la suma de comprobación CAN sin ningún control de integridad adicional en el nivel de la aplicación será suficiente. Si estás en una aplicación tan crítica donde no es lo suficientemente buena, entonces deberías estar mirando múltiples buses independientes y redundantes y otros esquemas de alto nivel de todos modos.

El bus CAN ya obtuvo un CRC de 15 bits para solo 8 bytes de datos + bytes de sobrecarga. Eso es un nivel de seguridad bastante alto. El CRC detectará todos los errores de un solo bit y la mayoría de los errores más grandes también.

Además, hay muchas otras medidas de seguridad presentes en CAN: relleno de bits, la alta frecuencia de muestreo de cada bit por el controlador CAN, el método de arbitraje del bus, la corriente de señal bastante alta, las señales diferenciales, etc. / p>

Descartar parte de sus datos para CRC adicional parece un poco paranoico, especialmente porque CRC es una de las medidas de seguridad más débiles aquí. Hay mejores cosas que podría hacer para aumentar la seguridad (si es necesario), como implementar una verificación de la integridad de los datos del software.

En CAN, hay dos sistemas para verificar la integridad de los datos:

• Como mencionó, hay la suma de comprobación . El CRC implementado en la CAN ISO puede detectar 5 errores.

• Pero también hay algo durante el protocolo, si una ECU ve un poco que no debería estar aquí en el bus CAN. El cambio está dañado y en su lugar se envía el cuadro de error . Una ECU puede corromper su propio marco si lee un bit diferente al que ha escrito.

Puede agregar otro mecanismo en la capa OSI superior, pero no creo que sea necesario para un uso normal.