Applications: Automotive
Applications: Automotive
and devices to communicate with each other within a vehicle without a host computer.
It was designed specifically for automotive applications but is now also used in other areas.
Development of the CAN-bus started originally in 1983 at Robert Bosch GmbH.[1] The protocol was
officially released in 1986 at the Society of Automotive Engineers (SAE) congress in Detroit, Michigan. The
first CAN controller chips, produced by Intel and Philips, came on the market in 1987. Bosch published the
CAN 2.0 specification in 1991.
Applications
[edit] Automotive
A modern automobile may have as many as 50 electronic control units (ECU) for various subsystems.
Typically the biggest processor is the engine control unit, which is also referred to as "ECU" in the context of
automobiles; others are used for transmission, airbags, antilock braking, cruise control, audio systems,
windows, mirror adjustment, etc. Some of these form independent subsystems, but communications among
others are essential. A subsystem may need to control actuators or receive feedback from sensors. The CAN
standard was devised to fill this need.
The CAN bus may be used in vehicles to connect engine control unit and transmission, or (on a different bus)
to connect the door locks, climate control, seat control, etc. Today the CAN bus is also used as a fieldbus in
general automation environments, primarily due to the low cost of some CAN Controllers and processors.
Bosch holds patents on the technology, and manufacturers of CAN-compatible microprocessors pay licence
fees to Bosch, which are normally passed on to the customer in the price of the chip. Manufacturers of
products with custom ASICs or FPGAs containing CAN-compatible modules, may need to pay a fee for the
CAN Protocol License.
[edit] Technology
CAN is a multi-master broadcast serial bus standard for connecting electronic control units (ECUs).
Each node is able to send and receive messages, but not simultaneously: a message (consisting primarily of
an ID — usually chosen to identify the message-type/sender — and up to eight message bytes) is transmitted
serially onto the bus, one bit after another — this signal-pattern codes the message (in NRZ) and is sensed by
all nodes.
The devices that are connected by a CAN network are typically sensors, actuators and control devices. A
CAN message never reaches these devices directly, but instead a host-processor and a CAN Controller is
needed between these devices and the bus.
If the bus is free, any node may begin to transmit. If two or more nodes begin sending messages at the same
time, the message with the more dominant ID (which has more dominant bits i.e. bit 0) will overwrite other
nodes' less dominant IDs, so that eventually (after this arbitration on the ID) only the dominant message
remains and is received by all nodes.
Bit rates up to 1 Mbit/s are possible at network lengths below 40 m. Decreasing the bit rate allows longer
network distances (e.g. 125 kbit/s at 500 m).
The CAN data link layer protocol is standardized in ISO 11898-1 (2003). This standard describes mainly the
data link layer — composed of the Logical Link Control (LLC) sublayer and the Media Access Control
(MAC) sublayer — and some aspects of the physical layer of the OSI Reference Model. All the other
protocol layers are left to the network designer's choice.
Certain microcontrollers, like some models of the PIC microcontroller family by Microchip Technology,
some models of any Renesas family and Atmel AVR and Atmel 8051, many Freescale Semiconductor
microcontrollers, as well as several ARM based microcontrollers have built-in CAN support.
This is achieved by CAN transmitting data through a binary model of "dominant" bits and "recessive" bits
where dominant is a logical 0 and recessive is a logical 1. This means open collector, or 'wired or' physical
implementation of the bus (but since dominant is 0 this is sometimes referred to as wired-AND). If one node
transmits a dominant bit and another node transmits a recessive bit then the dominant bit "wins" (a logical
AND between the two).
So, if you are transmitting a recessive bit, and someone sends a dominant bit, you see a dominant bit, and
you know there was a collision. (All other collisions are invisible.) A dominant bit is asserted by creating a
voltage across the wires while a recessive bit is simply not asserted on the bus. If any node sets a voltage
difference, all nodes will see it. Thus there is no delay to the higher priority messages, and the node
transmitting the lower priority message automatically attempts to re-transmit 6 bit clocks after the end of the
dominant message.
When used with a differential bus, a Carrier Sense Multiple Access/Bitwise Arbitration (CSMA/BA) scheme
is often implemented: if two or more devices start transmitting at the same time, there is a priority based
arbitration scheme to decide which one will be granted permission to continue transmitting. The CAN
solution to this is prioritised arbitration (and for the dominant message delay free), making CAN very
suitable for real time prioritised communications systems.
During arbitration, each transmitting node monitors the bus state and compares the received bit with the
transmitted bit. If a dominant bit is received when a recessive bit is transmitted then the node stops
transmitting (i.e., it lost arbitration). Arbitration is performed during the transmission of the identifier field.
Each node starting to transmit at the same time sends an ID with dominant as binary 0, starting from the high
bit. As soon as their ID is a larger number (lower priority) they'll be sending 1 (recessive) and see 0
(dominant), so they back off. At the end of ID transmission, all nodes but one have backed off, and the
highest priority message gets through unimpeded.
[edit] Layers
Based on levels of abstraction, the structure of the CAN protocol can be described in terms of the following
layers:
Application Layer
Object Layer
o Message Filtering
o Message and Status Handling
Transfer Layer
The Transfer Layer represents the kernel of the CAN protocol. It presents messages received to the
object layer and accepts messages to be transmitted from the object layer. The transfer layer is
responsible for bit timing and synchronization, message framing, arbitration, acknowledgment, error
detection and signaling, and fault confinement. It performs:
o Fault Confinement
o Error Detection
o Message Validation
o Acknowledgment
o Arbitration
o Message Framing
o Transfer Rate and Timing
o Information Routing
Physical Layer
The physical layer defines how the signals are actually transmitted. Tasks include:
o Signal Level and Bit Representation
o Transmission Medium
[edit] Frames
A CAN network can be configured to work with two different message (or "frame") formats: the standard or
base frame format (or CAN 2.0 A), and the extended frame format (or CAN 2.0 B). The only difference
between the two formats is that the “CAN base frame” supports a length of 11 bits for the identifier, and the
“CAN extended frame” supports a length of 29 bits for the identifier, made up of the 11-bit identifier (“base
identifier”) and an 18-bit extension (“identifier extension”). The distinction between CAN base frame format
and CAN extended frame format is made by using the IDE bit, which is transmitted as dominant in case of an
11-bit frame, and transmitted as recessive in case of a 29-bit frame. CAN controllers that support extended
frame format messages are also able to send and receive messages in CAN base frame format. All frames
begin with a start-of-frame (SOF) bit that denotes the start of the frame transmission.
The data frame is the only frame for actual data transmission. There are two message formats:
The CAN standard requires the implementation must accept the base frame format and may accept the
extended frame format, but must tolerate the extended frame format.
Length
Field name Purpose
(bits)
Start-of-frame 1 Denotes the start of frame transmission
Identifier 11 A (unique) identifier for the data
Remote transmission request
1 Must be dominant (0)Optional
(RTR)
Identifier extension bit (IDE) 1 Must be dominant (0)Optional
Reserved bit (it must be set to dominant (0), but accepted as either
Reserved bit (r0) 1
dominant or recessive)
Data length code (DLC)* 4 Number of bytes of data (0-8 bytes)
Data field 0-8 bytes Data to be transmitted (length dictated by DLC field)
CRC 15 Cyclic redundancy check
CRC delimiter 1 Must be recessive (1)
Transmitter sends recessive (1) and any receiver can assert a
ACK slot 1
dominant (0)
ACK delimiter 1 Must be recessive (1)
End-of-frame (EOF) 7 Must be recessive (1)
One restriction placed on the identifier is that the first seven bits cannot be all recessive bits. (I.e., the 16
identifiers 1111111xxxx are invalid.)
Length
Field name Purpose
(bits)
Start-of-frame 1 Denotes the start of frame transmission
Identifier A 11 First part of the (unique) identifier for the data
Substitute remote request
1 Must be recessive (1)Optional
(SRR)
Identifier extension bit (IDE) 1 Must be recessive (1)Optional
Identifier B 18 Second part of the (unique) identifier for the data
Remote transmission request
1 Must be dominant (0)
(RTR)
Reserved bits (it must be set dominant (0), but accepted as either
Reserved bits (r0, r1) 2
dominant or recessive)
Data length code (DLC)* 4 Number of bytes of data (0-8 bytes)
Data field 0-8 bytes Data to be transmitted (length dictated by DLC field)
CRC 15 Cyclic redundancy check
CRC delimiter 1 Must be recessive (1)
Transmitter sends recessive (1) and any receiver can assert a
ACK slot 1
dominant (0)
ACK delimiter 1 Must be recessive (1)
End-of-frame (EOF) 7 Must be recessive (1)
* It is physically possible for a value between 9-15 to be transmitted in the 4-bit DLC, although the data is
still limited to 8 bytes. Certain controllers allow the transmission and/or reception of a DLC greater than 8,
but the actual data length is always limited to 8 bytes.
•Generally data transmission is performed on an autonomous basis with the data source node (e.g. a sensor)
sending out a Data Frame. It is also possible, however, for a destination node to request the data from the
source by sending a Remote Frame.
•There are 2 differences between a Data Frame and a Remote Frame. Firstly the RTR-bit is transmitted as a
dominant bit in the Data Frame and secondly in the Remote Frame there is no Data Field.
i.e.
In the very unlikely event of a Data Frame and a Remote Frame with the same identifier being transmitted at
the same time, the Data Frame wins arbitration due to the dominant RTR bit following the identifier. In this
way, the node that transmitted the Remote Frame receives the desired data immediately.
The first field is given by the superposition of ERROR FLAGS contributed from different stations. The
following second field is the ERROR DELIMITER.
The overload frame contains the two bit fields Overload Flag and Overload Delimiter. There are two kinds of
overload conditions that can lead to the transmission of an overload flag:
1. The internal conditions of a receiver, which requires a delay of the next data frame or remote frame.
2. Detection of a dominant bit during intermission.
The start of an overload frame due to case 1 is only allowed to be started at the first bit time of an expected
intermission, whereas overload frames due to case 2 start one bit after detecting the dominant bit. Overload
Flag consists of six dominant bits. The overall form corresponds to that of the active error flag. The overload
flag’s form destroys the fixed form of the intermission field. As a consequence, all other stations also detect
an overload condition and on their part start transmission of an overload flag. Overload Delimiter consists of
eight recessive bits. The overload delimiter is of the same form as the error delimiter.
[edit] Standards
There are several CAN physical layer standards:
ISO 11898-2 uses a two-wire balanced signaling scheme. It is the most used physical layer in car powertrain
applications and industrial control networks.
ISO 11898-4 standard defines the time-triggered communication on CAN (TTCAN). It is based on the CAN
data link layer protocol providing a system clock for the scheduling of messages.
SAE J1939 standard uses a two-wire twisted pair, -11 has a shield around the pair while -15 does not. SAE
1939 is widely used in agricultural & construction equipment.
ISO 11783-2 uses four unshielded twisted wires; two for CAN and two for terminating bias circuit (TBC)
power and ground. This bus is used on agricultural tractors. This bus is intended to provide interconnectivity
with any implementation adhering to the standard.
[edit] Higher layer implementations
As the CAN standard does not include tasks of application layer protocols, such as flow control, device
addressing, and transportation of data blocks larger than one message, many implementations of higher layer
protocols were created. Among these are DeviceNet, CANopen, SDS (Smart Distributed System),
CANaerospace, J1939, NMEA 2000, CAN Kingdom, SafetyBUS p, and MilCAN.
An ARINC technical working group develops the ARINC 825 standard with special requirements for the
aviation industry