You are on page 1of 33

CAN Bus

CAN Introduction (1/2)


CAN (Controller Area Network) is a serial bus system, which was originally developed for automotive applications in the early 1980's. The CAN protocol was internationally standardized in 1993 as ISO 11898-1 and comprises the data link layer of the seven layer ISO/OSI reference model. CAN provides two communication services: the sending of a message (data frame transmission) and the requesting of a message (remote transmission request, RTR).

CAN Introduction (2/2)


The equivalent of the CAN protocol in human communication are e.g. the Latin characters.. CAN users still have to define the language/grammar and the words/vocabulary to communicate. CAN provides
a multi-master hierarchy, which allows building intelligent and redundant systems. broadcast communication. A sender of information transmits to all devices on the bus. All receiving devices read the message and then decide if it is relevant to them. sophisticated error detecting mechanisms and re-transmission of faulty messages.

History of CAN (1/2)


In February of 1986, Robert Bosch GmbH introduced the serial bus system Controller Area Network (CAN ) at the Society of Automotive Engineers (SAE) congress. Today, almost every new passenger car manufactured in Europe is equipped with at least one CAN network. Also used in other types of vehicles, from trains to ships, as well as in industrial controls, CAN is one of the most dominating bus protocols

History of CAN (2/2)


1983 : Start of the Bosch internal project to develop an in-vehicle network 1986 : Official introduction of CAN protocol 1987 : First CAN controller chips from Intel and Philips Semiconductors 1991 : Boschs CAN specification 2.0 published 1991 :CAN Kingdom CAN-based higher-layer protocol introduced by Kvaser 1992 : CAN in Automation (CiA) international users and manufacturers group established 1992 : CAN Application Layer (CAL) protocol published by CiA 1992 : First cars from Mercedes-Benz used CAN network 1993 : ISO 11898 standard published 1994 : 1st international CAN Conference (iCC) organized by CiA 1994 : DeviceNet protocol introduction by Allen-Bradley 1995 : ISO 11898 amendment (extended frame format) published 1995 : CANopen protocol published by CiA 2000 : Development of the time-triggered communication protocol for CAN (TTCAN)

CAN Protocol
The CAN protocol is an international standard defined in the ISO 11898. Beside the CAN protocol itself the conformance test for the CAN protocol is defined in the ISO 16845, which guarantees the interchangeability of the CAN chips. CAN is based on the broadcast communication mechanism, which is based on a message-oriented transmission protocol.

CAN Protocol
- Principles of data exchange

CAN Protocol
- Principles of data exchange
As a result of the content-oriented addressing scheme a high degree of system and configuration flexibility is achieved. It is easy to add stations to an existing CAN network without making any hardware or software modifications to the present stations as long as the new stations are purely receivers. This allows for a modular concept and also permits the reception of multiple data and the synchronization of distributed processes. Data transmission is not based on the availability of specific types of stations allowing simple servicing and upgrading of the network.

CAN Protocol
- Real-time data transmission
In real-time processing the urgency of messages to be exchanged over the network can differ greatly. The priority, at which a message is transmitted compared to another less urgent message, is specified by the identifier of each message. Bus access conflicts are resolved by bit-wise arbitration of the identifiers involved by each station observing the bus level bit for bit. This happens in accordance with the wired-andmechanism, by which the dominant state overwrites the recessive state. Transmission requests are handled in order of their importance for the system as a whole.

CAN Protocol
- Real-time data transmission

CAN Protocol
- Message frame formats

The CAN protocol supports two message frame formats, the only essential difference being in the length of the identifier. 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.

CAN Protocol
- Message frame formats

CAN Protocol
- Detecting and signaling errors
For error detection the CAN protocol implements three mechanisms at the message level:
Cyclic Redundancy Check (CRC) Frame check ACK errors

CAN Protocol
Detecting and signaling errors
The CAN protocol also implements two mechanisms for error detection at the bit level:
Monitoring: Each station that transmits also observes the bus level and thus detects differences between the bit sent and the bit received. Bit stuffing: The bit representation used by CAN is "Non Return to Zero (NRZ)" coding. The synchronization edges are generated by means of bit stuffing. This stuff bit has a complementary value, which is removed by the receivers.

Higher Layer Protocols


CAN hardware implementations cover the lower two layers of the OSI reference model while various software solutions (higher layer protocols) cover the layers three to seven.

Higher Layer Protocols


Models are used to understand communication, and to describe communication objects as well as services on these objects. Layered models are common in communication technology. To understand the CAN reference model easier you can use an analogy. Functionality provided by CAN is similar to Latin letters in human communication. It is the base for writing a language, but is not enough to start with efficient communication.

Physical Layer
CAN protocol defines the data link layer and part of the physical layer in the OSI model, which consists of seven layers. The International Standards Organization (ISO) defined a standard, which incorporates the CAN specifications as well as a part of physical layer: the physical signaling, which comprises bit encoding and decoding (Non-Return-toZero, NRZ) as well as bit timing and synchronization. The CAN physical medium is a two-wire bus line with common return terminated at both ends by resistors. Differential signal is used for better immunity. The following figure shows a transmit signal from a CAN controller, the differential signal emitted on the line and the receive signal received by the CAN controller to monitor the CAN bus.

Physical Layer
A typical CAN bus in a factory automation application is a single line bus with stubs to connect equipments such as PLC, Sensors, Drives etc as illustrated by the figure below :

CAN Design
- Physical Layout & Topology

Physical CAN Connection according to ISO 11898

Implementations of the CAN protocol


Communication is identical for all implementations of the CAN protocol. There are differences, however, with regard to the extent to which the implementation takes over message transmission from the microcontrollers which follow it in the circuit.
CAN controller with intermediate buffer. CAN controller with object storage. CAN slave controllers for I/O functions.

CAN Advantages
Is capable of providing real-time communication. Uses error correction and confinement, greatly helpful in noise-critical environments. Uses a lossless, bitwise arbitration scheme. High Speeds at Low-Cost. Suitability for small networks. The protocol is designed to increase integrity of the system. It is designed for control not transmission of large blocks of data.

CAN Microcontrollers
All CAN Microcontrollers have a set of common features: Flash memory for code E2PROM RAM In Application Programming capability assisted by a boot loader. Same CAN engine to simplify Software Migration. Low voltage capability (2.7 volts min) Enough MIPS to run high layer protocol + application

Atmel Solutions for CAN Networking


Atmel offer a family of product dedicated to advanced CAN bus standard (2.0A & 2.0B) with 80C51 core and AVR core. These microcontrollers with Flash memory provide the ultimate solution for designing advanced CAN based systems.
Performance range
Based on either 8051 or AVR core, the CAN 8-bit Flash microcontrollers achieve 5 MIPS or 16 MIPS processing speed respectively.

Powerful On-chip CAN Controller


V2.0A/V2.0B compliant Handles independent message objects programmable on-the-fly.

Easy Remote Programming and Field Upgrade


Highly flexible self-programming via CAN, UART, SPI, JTAG

Support Higher Layer Protocol Stacks


CANopen, DeviceNet, J939 and OSEK

Atmel Solutions for CAN Networking

CAN - Application
The Controller Area Network (CAN) serial bus system is used in a broad range of embedded as well as automation control systems. It usually links two or more micro-controller-based physical devices. Many industries have adopted the CAN bus standard, and gained a lot in reliability and flexibility. For some applications, the cost and speed to deploy or reconfigure a communication network is critical such as a factory floor for instance. A CAN bus can be laid out, then equipments can be added thanks to the plug and play capability of CAN with Higher Layer Protocols.

CAN in cars and truck engine control


Networking controllers for engine timing, transmission, chassis and brakes. Networking components of chassis electronics and electronics which make the vehicle more comfortable. Examples of such multiplex applications are lighting control, air-conditioning, central locking and seat and mirror adjustment.

CAN is used in the majority of European cars for engine control and body electronic. American and Asian car manufacturers are also implementing the CAN.

CAN in maritime applications


In maritime electronics CAN networks are used in boats, ships and vessels as embedded network in sub-systems and as integration network connecting several subsystems. Dedicated maritime devices with CAN connectivity exist, marine sub-systems with CAN interface as well as entirely CAN-based ship automation systems. Ship automation systems may comprise several physical CAN networks. A second category of maritime application is fishing industry as well as recreational boat. In such application we can find GPS, radar, sonar, fish finder, control dashboard, display plus various safety sensors.

CAN in avionics system network


CAN is used as a backbone network in aircrafts for flight state sensors, navigation systems and research PCs driving displays installed in the cockpit. Within the aircraft CAN networks are used to analyze in-flight data or together with a voice/video installation to analyze crew assistance provided by the cockpit interfaces. CAN is also used in aerospace applications, e.g. in engine control systems such as fuel systems, pumps and linear actuators.

CAN in medical equipments


CAN is used as embedded network in medial devices such as in X-ray machines. Complete operating rooms are equipped with a CAN network that manages all functions. CAN is deployed by the leader in hospital beds connecting the control panels the various motors, the scale. A hospital bed includes 5 to 10 CAN nodes in new generation of beds to be introduced in 2004 in the marketplace. X-ray collimator, X-ray generator and patient table from a market leader use CAN. In addition, complete hospital control systems with voltage control, indication and control units, multi cube power meters and digital I/O, and visualization software are networked via CAN.

CAN in environment research


The scientist of the Max-Planck-Institute (MPI) faced a difficult task of measuring and collecting data when they wanted to implement the project bio diversity. The project was started in the spring of 2003 in the valley of the Saale-river near Jena, on the grounds equivalent to 13 soccer pitches they planted over 400 meadow allotments and sowed 495 different mixtures of meadow plants Due to the spacious extent a decentralized measuring system was chosen; all communication is done via CANopen. In four independent CAN networks with an overall length of 4,500 m were installed a total of 220 soil temperature sensors, 110 soil water voltage sensors, 25 pressure sensors, 22 sensors for air temperature and humidity as well as 22 surface temperature sensors. Furthermore 25 pumps were needed to regulate the water content of the soil.

Other Applications
Factory automation Industrial machine control Lifts and escalators Building automation Non-industrial control Non-industrial equipment

Thank You

Shreyas Nangia 200301123 Arun Agrawal 200301154 Mohit Gupta - 200301197

You might also like