¿Prueba de comunicaciones seriales ideal?

0

Estoy trabajando en un nuevo sistema de controlador de motor personalizado que he heredado. El sistema tiene una jerarquía de controladores: una PC se comunica con un bus serie RS-485 de un nivel de controladores, y cada uno de estos se comunica con su propio bus de controladores RS-485. El sistema utiliza un protocolo de paquetes personalizado con una suma de comprobación simple de 8 bits y sin esquema ACK / NAK. La longitud máxima del paquete es de 256 bytes. Me gustaría realizar una prueba de comunicaciones realmente exhaustiva para el sistema, una que podría dejar funcionando durante unas horas en un sistema probándola tanto como sea posible para cualquier tipo de corrupción de datos. ¿Cuál sería la forma ideal de hacer esto? ¿Sería mejor probar un patrón de datos conocido o datos pseudoaleatorios? Si un patrón de datos conocido, ¿cuál debería ser el patrón? ¿Sería mejor probar paquetes de datos cortos o paquetes de longitud máxima o combinaciones variables? Sé que hay un montón de buenos algoritmos para probar RAM, así que estoy ansioso por aprender cómo probar mejor las interfaces seriales.

    
pregunta fred basset

3 respuestas

0

Puede considerar las pruebas HALT / HASS sobre la solidez de la red de comunicaciones.

Conisder Fault: inyección para probar respuestas de alto y bajo nivel con varios niveles y frecuencias de ingreso de ruido requeridas para causar errores por fuentes de ruido irradiadas o conducidas.

  • detección de fallas, recuperación, registro, aislamiento de fallas
  • Ruido conducido en AC DC y líneas de canales de comunicación.
  • Pulsos transitorios de línea de potencia (PLT), pulsos de transitorios de cable cercanos o ruido de impulso ESD irradiado desde una antena de plano metálico que utiliza descarga de alta tensión con rep. tasa.
  • pruebas de margen en la tensión de alimentación, tensión térmica, vibración aleatoria o herramienta de vibración pulsada
  • pruebas de rotor bloqueado
  • considere los patrones de datos del caso más desfavorable, si los hay, el alcance de un extremo al otro para el margen.

BER está directamente relacionado con SNR. Se espera que el canal ideal esté libre de errores, pero en realidad, ¿puede garantizar la SNR ideal? ¿Es una señal digital pura o es posible el ingreso?

A menudo he hecho suposiciones falsas en los diseños de mis canales de comunicación anteriores en los años 70 y aprendí mi lección. Nunca asumas y pruebes el margen de HALT HASS en caso de fallo y encuentro los enlaces más débiles.

    
respondido por el Tony EE rocketscientist
4

¿Qué quieres probar exactamente?

  • el manejo de mensajes (capas superiores de su sistema)
  • el concepto de comunicación, incluido el tiempo de respuesta, el manejo de errores, etc., o
  • el concepto de capa de hardware, que incluye cableado, reflexiones, interferencias, número variable de nodos, etc.
  • la configuración específica que está creando (con o sin factores externos)

En algún momento, todos necesitarán pruebas y requerirán diferentes enfoques. Cuando declara que la "corrupción de datos" es un tema importante y está hablando de una configuración específica, ¿supongo que se refiere a la última viñeta? En ese caso, me gustaría una combinación de pruebas aleatorias y específicamente pruebas de los peores casos que se puedan imaginar. (Las pruebas aleatorias pueden indicar casos peores adicionales que puede identificar e incluir explícitamente). Tenga en cuenta que una prueba realmente completa incluiría establecer sus márgenes, por lo que tendría que variar, por ejemplo, el tiempo de alimentación y la tensión de alimentación del controlador, las resistencias de terminación y la longitud del cable. Y luego hay factores externos ...

    
respondido por el Wouter van Ooijen
1

Recientemente tuve que escribir una envoltura de comunicación entre una pequeña computadora integrada y un PLC industrial. El PLC usó el protocolo estándar MODBUS sobre rs-485. Para probar la comunicación simplemente hice un diccionario de comandos y respuestas esperadas. Utilicé Python y simplemente registré todas las transmisiones y resolví las fallas. Estaba probando más de un conjunto de comandos de un protocolo conocido, por lo que puede ser un escenario ligeramente diferente.

    
respondido por el sptrks

Lea otras preguntas en las etiquetas