AUTOMOTIVE ELECTRICAL & AIR CONDITIONING NEWS
Common types of CAN
This article is the second in a series of articles by Jason Turner and Clinton Smith from REDARC. They are writing about the latest in CAN and developments in this rapidly changing field.
Turner & Smith are degree qualified Electronics Design Engineers from REDARC Technologies who design, develop and manufacture smart electronic products for the Automotive Industry. In their work at REDARC, they have gained significant experience in Control Area Network (CAN) training and consulting, module design, development and manufacturing.
The experience gained by this pair in this area has been further enhanced by representing REDARC at both the 14th International CAN Conference (ICC) held in November 2013 in Paris, France and the 13th ICC held in March 2012 in Hambach, Germany.
The conference, conducted by CAN in Automation (CiA) who is the international users’ and manufacturers’ organization that develops and supports CAN-based higher-layer protocols, covers many CAN-based topics with presenters and attendees representing companies from all aspects of CAN development , from chip-makers to system designers, automotive OEMs, to designers, and of course end-of-line product designers. REDARC has previously been represented at these conferences since 2005. This article will discuss some common types of CAN, or more correctly, common ‘CAN physical layer standards’.
FIRSTLY, LET’S LOOK AT an example of how CAN is used in a vehicle as shown in the picture above. A vehicle rarely uses just a single CAN bus. Normally a vehicle will use multiple busses separated into groups defined by factors such as priority, safety, and how critical timing is for the devices on the bus. This way the characteristics of the bus can be tailored to suit the requirements of the devices, and we can ensure that low priority tasks such as turning on your seat warmer don’t interfere with higher priority tasks such as changing gears.
The separate busses are usually connected to gateways that decide what messages can cross from one bus to another, as well as converting the messages to match the type used on the bus it is crossing to.
In this example we can see that there are two different types of CAN busses (HS-CAN and LS-CAN) as well as another type of bus called LIN, which we will examine later.
Let’s take a look at some common types of CAN, or more correctly: common ‘CAN physical layer standards’, starting with HS-CAN.
High speed CAN is probably the most common type of CAN. It doesn’t have a defined bit rate, but the term encompasses all bit rates up to and including 1Mbps. It uses the standard two-wire twisted pair physical layer and is often found in cars and industrial applications. It is defined by the standard ISO 11898-2.
Fault tolerant CAN, also known by the name low speed CAN (LS-CAN) is similar to HS-CAN in almost every way, except that it operates up to a maximum bit rate of 125kbps. By operating at a lower speed, it is more fault tolerant and can handle more significant faults, such as losing one of the CAN wires. FT-CAN uses different transceivers to HS-CAN that are able to fully support this functionality. Devices on a FT-CAN bus generally are not so timing critical, so the slower bus speed has little effect. FT-CAN is defined by ISO 11898-3.
Another type is single wire CAN, which – as the name implies – only uses one wire. Again, to compensate for this and ensure reliability, the bit rate is dropped to a maximum of 40kbps. This type of CAN is used mostly in automotive applications and is defined by SAE J2411. However, since this type of CAN is close to the speed of LIN (which is also a single wire protocol) it is more common for LIN to be used as the cost of implementation is less than CAN.
The last type of CAN we will discuss is called SAE J1939-11 (and 15). Technically speaking, this type of CAN is not really a new type as it conforms fully to ISO 11898-2 (or HS-CAN), however it goes into more detail than HS-CAN. In this standard, the bit rate is set to a fixed 250kbps, and the ‘-11’ standard defines shielded twisted pair wires, whereas the ‘-15’ standard defines unshielded twisted pair; other than that the two are identical. This is the physical standard you will find is used as the main CAN bus in heavy vehicles, and since the standard is so specific, it explains why it is so compatible across the entire trucking industry. This physical standard is associated with an application layer protocol also known as J1939, but has the suffix ‘-71’. We will also discuss that standard later on.
We have discussed “physical layers” and “application layers”, but what exactly are these? These terms relate to what is called the “Seven Layer Open Systems Interconnection Model” or OSI Model. This is all just a fancy way of breaking down communication systems into smaller parts, or layers, which can then be standardised to make networking easier. These layers are: application, presentation, session, transport, network, data link and physical.
Most types of communications systems conform to this sort of structure, though they may not define every single layer. CAN is a prime example of this. Only the bottom two layers are defined by the standard (CAN specification 2.0). You can see I’ve listed a couple of the physical layer standards I previously mentioned, in particular ISO11898 which defines a 5V differential pair standard; both the J1939 and DeviceNet physical layers shown here are based on ISO11898.
While these two bottom layers are what is known as CAN, on their own they are not much use. For these layers to be useful, there must be some form of Higher Level Protocol to use them, and this is where the CAN Application Layer appears. It is the application layer that defines what messages are and what they mean.
If we take sending a friend a hand-written letter as an example and look at it in terms of the OSI model, the physical layer would be represented by the actual page as well as the ink on that page. The data-link layer would be represented by the Latin character set (alphabet); and the words, sentences and phrases that make sense of all this would be the application layer. The other layers inbetween make up the delivery method, for example the postal system.
The three application layer protocols listed here are the ones we’ll look at later, and are three of the most common CAN application layers in use.
But first, let’s look at the physical and datalink layers. While different standards specify different connectors and the like, most standards use the same configuration for the bus itself, that is a two wire differential (twisted pair) bus with an impedance of 120 Ohms on either end.
These terminating resistors are usually placed in devices that appear at either end of the bus, and that are unlikely to ever be removed from the bus – such as the engine ECU or perhaps the Transmission ECU. Other devices can then be added to the bus between the two end nodes.
If we observe the voltage levels on the bus, we can see that when no nodes are transmitting the voltage level on the two bus lines are the same. This is what is known as the ‘recessive’ state and corresponds to a logical ‘1’ read by devices on the bus. When a device transmits a logical ‘0’ (e.g. to start sending a message) then the transceiver pulls the two CAN lines towards their respective limits; this is known as the ‘dominant’ state.
In simple terms you could view it as if only the dominant bits are transmitted and then the recessive bits are simply the gaps in between where the bus is allowed to return to its default state. By viewing it in this way, it is clear to see that if one device tries to transmit a dominant bit at the same time as another tries to transmit a recessive bit, then the dominant bit would ‘win’.
If we look at CAN high with respect to CAN low (as they are differential), we see approximately zero volts for a recessive bit, and nominally two volts for a dominant bit (though the acceptable range is 0.9V to 5V). Don’t get confused by this, a recessive bit is still represented by a logical ‘1’, and dominant as logical ‘0’, despite the subtraction of the signals making it look like it is the other way around – this is simply due to the way the transceivers work.
So you can see what an actual CAN bus looks like, here is a screen capture of a real CAN message from an oscilloscope.
As with any communication system, there are limitations. In the case of CAN there are three main limiting factors when it comes to bus length, these are bit rate, the number of nodes on the bus and the layout of the bus.
Assuming a bus has a relatively small number of nodes, and uses the standard straight-line topology mentioned earlier, a rough guide of the maximum bus length versus data rate is as follows: see full article for this image.
By decreasing the data rate, you can significantly increase the length of the bus. That being said, while this guide shows what is technically possible, most standards will specify maximum bus lengths to be much less than this to ensure reliability. For example, J1939 operates at 250kbps but the standard specifies a maximum bus length of 40m (1m drop length, max 30 nodes).
That covers how the physical part of a CAN bus is constructed and in our next article we will focus on the data aspect of CAN.
If you have any questions or would like further information please do not hesitate to email Jason Turner at REDARC - firstname.lastname@example.org - CAN node 1 or call (08) 8322 4848.
To view the full article and diagrams/images please click the link below.