The CAN'T Bus
Don’t you just love modern day IT terminology? I mean it’s so graphic, so descriptive and often without even knowing the purpose of the feature or component, simply hearing the name gives you a pretty good idea. Thus for instance, we have floppy discs which were, at least initially – floppy, and hard discs that are well, – hard! Thus when we hear the term CAN Bus, without fully understanding what might be going on and ignoring the pre-fix, our imagination conjures up pictures of people in a bus travelled up and down a road. At each stage along the way, people get on and off and carry their shopping home to their loved ones and even though there may be many buses travelling back and forth along the route, for some reason they never (or very rarely) seem to crash into each other. And so, as with modern urban transport systems, the transport system providing data backwards and forwards between the sensors and the engine ECU, can use precisely the same philosophy.
As I remember I first came across it in the mid 1980s. Concerned that car doors were being loaded with so many electric components – central locking, electric windows, adjustable rear-view mirrors, heated rear view mirrors, and that the volume / weight of the additional wiring was bringing reliability issues, a wiring system was developed to reduce these wires to just two. The system was known as multiplexing. And over time when engines and gearboxes were controlled by ECUs and the amount of electronics and shear weight of the wiring became an issue, this multiplexing evolved into the standard, developed at Robert Bosch as CAN Bus or Controller Area Network Bus.
Originally designed to handle short messages (up to 8 bytes), support multi-master access (collisions being avoided through a system of priority) with a high degree of reliability, today virtually every passenger car manufacturer incorporates at least one such module in its electrical system. Offering a significant reduction in wiring – reducing weight and cost, and minimising the number of connections giving improved reliability – the CAN bus is effectively a pair of twisted wires (one ‘high’, one ‘low’), which transmit a series of digital messages, either 1s or 0s according to a given protocol and between ECUs. Devices connected by the CAN network will be sensors, actuators and their controlling devices with messages being loaded and downloaded along the way (effectively the bus stops) at various nodes.
Now the sensors used for most engine management systems will be of reasonable quality and provide sufficient resolution to ensure that the engine works satisfactorily to within certain performance criteria. The information they supply to the bus however will not be accurately calibrated and anybody using this information for engineering research / development purposes will introduce a level of uncertainty into their measurements as to make them, if not totally useless, then certainly suspect. The only way to get high quality development data is to use good quality transducers calibrated to your requirements. The CAN Bus data, while convenient, is not always up to this standard. As one data logging expert said to me recently, “They think they have accurate data but could end up seriously misleading or confusing themselves.”
Maybe a case of the CAN Bus which can’t?
Written by John Coxon.