Pérdida de paquetes en CAN

5

¿Qué tan susceptible es un bus CAN a la pérdida de paquetes, y cuáles son las fuentes de pérdida de paquetes en CAN?

Me doy cuenta de que la respuesta puede depender en gran medida de la aplicación, por lo que aquí hay algunos detalles:

  • longitud del autobús: aproximadamente 1 m.
  • utilización del bus: potencialmente alta.
  • # de nodos: 5-20.

El bus es para uso en prótesis de brazo. Me pregunto cuál es la necesidad de un sistema de número de secuencia / acuse de recibo explícito para la comunicación periódica de los datos del sensor.

Si alguien sabe algo acerca de esto, o sabe de un documento que lo discute con cierto detalle, sería muy útil.

Gracias.

    
pregunta oyvind

2 respuestas

5

Los paquetes solo se pierden si se produce un error, por lo que la respuesta es en gran medida un "depende de los niveles de ruido" :) Solo un nodo "posee" el bus en cualquier momento y todos los nodos concuerdan con quién debería ser ( al final de la fase de arbitraje). Al final del mensaje, habrá un acuse de recibo de cada nodo que recibió el mensaje correctamente y, potencialmente, un acuse de recibo negativo de cualquier nodo que lo haya recibido de manera incorrecta. Si ese NAK está presente, todos los nodos invalidarán el mensaje y esperarán un nuevo intento.

Sin embargo, las partes de detección y recuperación de errores de CAN solo están pensadas como una solución a errores aleatorios. En un sistema de producción, desconfiaba de cualquier bus que mostrara algún cuadro de error durante la "operación normal".

Otra cosa que podría considerarse "pérdida de paquete" es un paquete regular de baja prioridad, que puede no ser capaz de arbitrar su camino en el bus con la frecuencia suficiente. Y si su controlador CAN está basado en FIFO (en lugar de verdaderos objetos de mensaje, cada uno de los cuales puede arbitrar la prioridad internamente), puede contener mensajes de mayor prioridad. Las simulaciones del sistema pueden ayudarlo a evaluar con qué frecuencia puede ocurrir.

En mi experiencia (automotriz), los números de secuencia se usan a menudo como una verificación contra el software que se vuelve loco y simplemente transmite el mismo cuadro una y otra vez. Cualquier ACK / RETRY se deja a las capas de protocolo inferior.

He visto sistemas con un bus CAN muy (muy!) eléctricamente ruidoso que muestra varios cuadros de error por segundo (!) ... funcionó, pero tuvo secuencias muy ocasionales de errores que hace que una de las ECU se salga del bus. No recomendado.

Otro ejemplo de la tolerancia de error de CAN fue un sistema que (en un desarrollo muy temprano) requería un UART; el único pin disponible era el pin de habilitación CAN. Incluso con el encendido y apagado del conductor del autobús (por la UART a 115200 bps), los mensajes aún se transmitieron. De nuevo, con una alta tasa de errores en el bus, ¡pero los reintentos llegaron al final! Y de nuevo, no recomendado!

    
respondido por el Martin Thompson
3

CAN es bastante robusto siempre que los controladores que están enganchados puedan manejar los errores sin problemas.

  1. Simplificar la comunicación ayudaría mucho. Las capas pueden hacerte gastar mucho Tiempo para procesar los datos. Si sus buzones de correo son limitados, se puede sobrescribir. Es un una buena idea para ejecutar esas tareas en la rutina de servicio de interrupción.
  2. Use marcos remotos en lugar de mensajes periódicos que podrían saturar el bus.
  3. Si un nodo se apaga, asegúrese de que cuando se enciende, se inicialice correctamente.
  4. La terminación debe estar siempre disponible.
  5. Cuando un nodo BUSOFF, no debe volver a intentarlo hasta un tiempo razonable, digamos 5 segundos o tu ciclo de poder
  6. EMC podría ser bueno si está enviando basura de forma periódica, pero no es bueno para ID más altas. ganar el arbitraje.

Corolla tiene 27 cajas en el bus CAN y no verías ni un solo cuadro de error durante años.

    
respondido por el Kasimani Baskaran

Lea otras preguntas en las etiquetas