I'm working on a new customized motor controller system I've inherited. The system has a heirarchy of controllers - a PC communicates to an RS-485 serial bus of one level of controllers, and each one of these communicates to it's own RS-485 bus of controllers. The system uses a customized packet protocol with simple 8 bit checksum and no ACK/NAK scheme. Maximum packet length is 256 bytes. I'd like to come up with a really thorough communications test for the system, one I could leave running for perhaps hours on a system testing it as much as possible for any type of data corruption. What would be the ideal way to do this? Would it be better to test a known data pattern, or pseudo random data? If a known data pattern, what should the pattern be? Would it be better to test short data packets or maximum length packets or varying combinations? I know there are a lot of good algorithms out there for testing RAM so am eager to learn of how to best test serial interfaces.
3 Answers
You can consider HALT/HASS tests on how robust the communication network is.
Conisder Fault injection to test high level and low level responses with various levels and frequencies of noise ingress required to cause error by radiated or conducted noise sources.
- fault detection, recovery, logging, fault isolation
- Conducted noise on AC DC and comm channel lines.
- Radiated power line transient (PLT) pulses, nearby cable transients pulses or radiated ESD impulse noise from a metal plane antenna using HV discharge with rep. rate.
- margin tests on power supply voltage, thermal stress, random vibration or pulsed vibrating tool
- stalled rotor tests
- consider worst case data patterns if any, scope end to end channel for margin.
BER is directly related to SNR. Ideal channel is expected to be error free, but in reality can you guarantee ideal SNR? Is a pure digital signal or is ingress possible?
I have often made false assumptions in my past communication channel designs in the 70's and learnt my lesson.. Never assume and test margin for HALT HASS to failure and find weakest links.
What exactly do you want to test?
- the message handling (upper layers of your system)
- the communication concept, including response timing, error handling, etc, or
- the hardware layer concept, including cabling, reflexions, interference, variable number of nodes, etc
- the specific configuration you are building (with or without external factors)
At some point these will all need testing, and will require different approaches. As you state "data corruption" as an important issue and you are talking about a specific setup I guess you mean the last bullet? In that case I would go for a combination of random testing and specifically testing the worst cases you can think of. (Random testing might indetify additional worst cases that you can identify and include explicitly.) Note that a realy thorough test would include establishing your margins, so you would need to vary for instance the driver's timing and supply voltage, the termination resistors, and the cable length. And then there's external factors...
Recently I had to write a communication wrapper between a small embedded computer and an industrial PLC. The PLC used standard MODBUS protocol over rs-485. To test the communication I simply made a dictionary of commands and expected responses. I used Python and simply logged all transmissions and sorted out faults. I was testing more of a command set of a known protocol so it may be a slightly different scenario.
