Designing a CAN network

When designing a CAN physical network, you have to make some general decisions. First of all, you need to choose the required data throughput. In theory, you can't overload the CAN network. You can only delay lower-prior messages, but then your application does not work properly. For a short time, busloads above 50 percent are acceptable. But an average busload of 50 percent should not be exceeded.

Now you can calculate the necessary transmission speed, which is the number of message bits doubled to be sent in a dedicated time window (e.g. one second). You can and should ask the software system designer to reduce the communication as much as possible. It is recommended to communicate as little as possible, but as much as necessary. Avoid communication without new information (CANopen offers you many options to do so, due to its flexible parametrization of messages). If you have optimized your busload and know the minimum bit-rate you need, you can calculate the maximal achievable network length.

You can also do it the other way around, of course: You take the needed network length and determine the possible maximum bit-rate. Here, you should optimize the communication to a minimum too. If possible, always use the minimum bit-rate, because the lower the speed, the more robust the communication.

You have more options to optimize your design. First of all is the topology: use a line topology terminated at both ends with resistors matching the impedance of all other physical layer elements (cable, connector, etc.). When using bit-rates much higher than 1 Mbit/s (CAN FD), even the impedance of micro-controller ports can be an issue. Star and mixed topologies limit the achievable speed/length ratio. It is recommended to keep the not terminated stubs and branches as short as possible. Even carmakers often using star topologies consider going for line topologies when introducing CAN FD communication.

If the network is quite long, it is recommended to use galvanic isolation. But this shortens the maximum length or speed due to the additional delay caused by the transformer or optocoupler. You should also use twisted-pair cables and if necessary you should shield them, in particular in noisy environments.

Most new designs are based on the CAN high-speed physical layer (ISO 11898-2). The transceivers are optionally available with low-power functionality. This means, the ISO 11898-3 approach (low-power, fault-tolerant limited to 125 kbit/s) is not state-of-the-art any longer. The single wire CAN (SAE J1411) is no option anyway, due it being slow and not robust.

Standardized or proprietary application layer?

This is a political or commercial question. If you need to buy off-the shelf products for low-volume applications, standardized application layers offer a lot of benefits. If you want to protect your communication system, you may implement your own application layer. But be aware that reverse engineering is not that difficult.

CANopen optimized for embedded network design is always an option. It provides a number of profiles allowing devices interoperability and partly interchangeability. Additionally, CANopen offers the possibility of manufacturer-specific parameters.

Other higher-layer protocols such as DeviceNet and the various J1939 versions are optimized for specific applications. In some markets, you have to chosen them because customers are trained and experienced in using them.

As a system designer, you should also observe the market on generic system design tools. If your volume is high enough, you can build your own tool chain. But even the automotive industry prefers to buy them from suppliers.

Pre-tested components and devices

Most of the micro-controllers with on-chip CAN modules are tested. The automotive industry requires CAN controllers that have passed the conformance testing according to the ISO 16845 series. Device makers implementing CANopen or DeviceNet or Isobus should also test the conformance of the application layer functions.

Conformance testing is like spell checking: It doesn’t prove interoperability. CiA provides CANopen interoperability tests and plug fests, in which the interoperability is tested as well. The CANopen conformance test tool includes an EDS (electronic data sheet) test, which proves the interoperability with CANopen design and configuration tools. EDSs are used as an exchange format between tools.