Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
16Activity
0 of .
Results for:
No results containing your search query
P. 1
Controller Area Network (CAN)

Controller Area Network (CAN)

Ratings:

5.0

(2)
|Views: 931|Likes:
Published by api-3754722

More info:

Published by: api-3754722 on Oct 17, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

03/18/2014

pdf

text

original

Controller Area Network
From Wikipedia, the free encyclopedia
(Redirected from Controller area network)
\u2022 Find out more about navigating Wikipedia and
finding information\u2022
Jump to:navig ation,search
Controller Area Network(CANor CAN-bus) is a computer network protocol andbus
standard designed to allow microcontrollers and devices to communicate with each
other and without a host computer.
It was designed specifically for automotive applications but is now also used in other
areas.
CAN is also supported in the Linux Kernel since the 2.6.25 version.
Contents
[hide]
\u2022
1 Origins
\u2022
2 Applications
o
2.1 Automotive
\u2022
3 CAN Network Testing
\u2022
4 Technology
\u2022
5 Data transmission
\u2022
6 Bit timing
\u2022
7 Layers
\u2022
8 Frames
o
8.1 Data frame
\ue000
8.1.1 Base frame format
\ue000
8.1.2 Extended frame format
o
8.2 Remote frame
o
8.3 Error frame
o
8.4 Overload frame
\u2022
9 Interframe spacing
\u2022
10 Bit stuffing
\u2022
11 Standards
\u2022
12 Higher layer implementations
\u2022
13 See also
\u2022
14 References
\u2022
15 External links
[edit] Origins
CAN-bus was originally developed in1988 by Intel Corporation and Robert Bosch
GmbH[1]
[edit] Applications
[edit] Automotive
A modern automobile may have as many as 50 control units for various subsystems.
Typically the biggest processor is the Engine Control Unit; 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 is 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 afieldbus in general automation environments: this is
especially because of the cheap prices of some CAN Controllers and processors. On the
other hand any official use of CAN requires that a fee for the CAN Protocol License is
to be paid to Bosch who developed the protocol and hold patents.

[edit] CAN Network Testing

Unforeseen problems incorporated into CAN based system are often contributed from the design methods used for the system and the individual component implementations. Scheduling methods which take into account the timing related to ECU software and hardware architecture, communication driver performance, and the network arbitration are required for minimizing the effort of testing required prior to manufacturing.

The development of distributed network based systems often utilizes multiple suppliers
for the prototyping of different modules and sub-systems. In order to best control the
complexities incorporated from such a distributed developmental process, the Original
Equipment Manufacturer usually requires a set of standard tests and procedures to be
run on the prototypes prior to delivery.

These tests usually require the prototype ECU to be connected to a simulated system
where performance measurements can be made for consideration of the physical layer,
communication layer, and application layer. The standard tests are run repeatedly until
the Device Under Test (DUT) passes all necessary tests. The requirements for testing
vary depending on the Original Equipment Manufacturers focus and may include
portions of the following sample test sequence:

Voltage Characteristic Protection Tests: Hardware Immunity to Ground Short,

Hardware Damage Immunity to Source Voltage Short, Hardware under voltage
operation characteristics Communication Waveform Characteristics: Transceiver tests
(short to GND, short to VBAT, ect.), Signal Integrity (I-diagrams), Signal Jitter
Analysis, Noise Injection Tests

Software Recovery from Error Conditions: Bus Off Conditions
Response Times: Functional Ages, Publisher Delays, Subscriber Delays, Gateway
Delays
Communication: First Frame Timing, Wakeup Sequence, Periodic Frame Times, Event
Frames
Network Management: Startup, Participation, Modes, Shutdown
Diagnostics: Recognition of faults, Module Reflashing

The supplier module level testing cleans up a majority of issues, however the greatest
task of identifying and troubleshooting issues is often confronted during the integration
testing phase. The integration testing phase requires that the \u201clive\u201d ECU\u2019s be
interconnected for the first time and the ultimate goal of this phase is to eliminate all
causes of system behavior which may negatively impact the manufactured products
reliability.

Time constraints require efficient use of test processes, available resources and tools to
ensure the highest levels of product quality are delivered at the conclusion of the
integration testing phase. Testing teams must possess a means for identification and
isolation of faults, along with the experience needed for quickly assessing possible root
causes. The time required for actually tracking down and solving the root failure mode
can often be extremely difficult and not time effective in widely distributed processes.

Testing tools must be scalable, flexible, and integrate able to provide test coverage for
all pertinent levels of the OSI model. The ideal test tools themselves must provide the
knowledge and know-how of skilled engineers by identifying questionable conditions,
and then using reasoning to guide the test engineer in solving the issue. The tool should
also be easily configurable, comprehensive, include predefined test libraries, and
provide extremely reliable measurements..

[edit] Technology
CAN is a broadcast (bus), differential serial bus standard for connectingel ectron ic
control units(ECUs).

Each node is able to send and receive messages, but not simultaneously: a message
(consisting primarily of an ID \u2014 usually chosen to identify the message-type/sender \u2014
and up to 8 message bytes) is transmitted serially onto the bus, one bit after another \u2014
this signal-pattern codes the message (inNRZ) and is sensed by all nodes.

The devices that are connected by a CAN network are typicallysensors,ac tuators 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 ie. 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.

Activity (16)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
Ladit Kévin liked this
Martin Rodriguez liked this
extrem45 liked this
Herry Montzer liked this
Gurpreet Singh liked this
pradeepmanral liked this
ecpuneetsharma liked this
braj87 liked this

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->