Вы находитесь на странице: 1из 21

Course Introduction

Purpose
This training course provides an introduction to Controller Area
Network (CAN) technology, which is used to build networked,
multiprocessor embedded systems.
Objectives
Understand what CAN technology is, why its important and
where it can be a good design solution.
Learn the fundamental operating concepts and capabilities of
CAN implementations.
Find out how CAN fits into the 7-layer OSI model.
Content
19 pages
3 questions
Learning Time
30 minutes

Welcome to the Part-1 introductory course on the basics of controller area


network (CAN) technology. This course provides technical details that will
help you design reliable, cost-effective distributed systems that link together
a network of microcontrollers (MCUs). To get the most out of the material
presented, you should be familiar with data communication networks in
general and understand the fundamentals of designing and developing
embedded control systems.
In this course, we will present an overview of CAN technology what it is,
why its important, and where it is used and can be applied to good
advantage. Then, we will highlight various key CAN design aspects,
including the physical interface, data flow, timing issues, Physical layer, OSI
model, and higher-level protocols used in CAN-based systems. At the end,
we include a helpful glossary of key terms.
The CAN Basics Part-2 course discusses Message Frames, bus errors and
network implementation strategies. Other online CAN courses at Renesas
Interactive cover the Application Programming Interface (API) for the CAN
peripheral built into microcontrollers in the Renesas R8C and M16C product
groups. These courses also provide additional design information for
implementing CAN-based multiprocessor systems.

What is CAN?
Controller Area Network:
Two-wire, bidirectional serial-bus communication method
Originally developed in the mid 1980s by Bosch for
automotive use
Main design objective: economical solution for implementing
high-integrity networking in real-time control applications
Now standardized internationally:
CAN 2.0A: ISO11519 low speed
CAN 2.0B: ISO11898 high speed
CAN Validation: ISO16845

Usage exceeded 200,000,000 nodes in 2001, still growing at a


30% rate annually
Many current and potential non-automotive application opportunities

The Controller Area Network (CAN) is a two-wire (twisted-pair), bidirectional


serial-bus communication method that allows electronic subsystems to be
linked together and interact in a network. It was originally developed in the
mid 1980s by Bosch for use in automotive applications, where it replaces
point-to-point wiring.
CAN is noted for its high integrity for real-time applications. It performs well
in noisy environments, for example, because CAN hardware incorporates
features designed to ensure reliable communication.
CAN specifications are international standards, and two versions are now in
use. CAN 2.0A, the low-speed version sometimes known as Basic or
Standard CAN, is defined by the ISO11519 standard. CAN 2.0B, the highspeed version, is also known as Full CAN or extended-frame CAN. It is
defined by the ISO11898 standard. ISO16845 covers CAN validation.
CAN is finding use in a growing number of non-automotive applications.
Usage exceeded 200,000,000 nodes in 2001 and has grown at a 30% rate
annually since then.

Non-automotive CAN Applications

Electronically controlled production and


packaging equipment
Machine tools; machines for molding, weaving, knitting,
and sewing; systems for folding and wrapping; etc.

Industrial freezers, printing machines


Ships, locomotives, railway systems
Farm and construction machinery
Semiconductor manufacturing equipment
Building automation: HVAC systems, elevators, etc.
Hospital patient-monitoring systems
Many others

More application information available at: www.canopen.us

Here we list some of the non-automotive applications that now use CAN
technology or are excellent candidates for using it. They span a wide range
and include production and packaging equipment, industrial freezers, highspeed printing machines, ships, locomotives and other elements of railway
systems, machinery used in farming and building construction,
semiconductor manufacturing equipment, building automation systems, and
patient monitoring systems in hospitals and clinics. Many others exist, as
well.

Key Reasons for Using CAN


1.

Reliability

2.

Error-free communication

Economy

Low wiring cost

Low hardware cost

3.

Scalability

Easy expandability

Low node-connection costs

4.

Availability

More chips with CAN hardware

More off-the-shelf tools

Higher-level protocols

5.

Popularity

Knowledge base expanding

Having briefly discussed what CAN is and where it can be used, lets now look at five main
reasons why its an excellent choice for implementing networked communication in embedded
systems.
First, CAN technology has been carefully designed to provide very reliable, error-free network
communication. This is a major issue for some types of safety critical equipment and real-time
systems.
Second, since the bus is a simple twisted pair wire, network wiring cost is low. Moreover, the
peripheral circuit that implements connectivity in the microcontroller doesnt occupy too much
chip area, which helps to keep MCU cost low, usually less than a few dollars more than a
device with the same features except CAN.
Third, the CAN network is readily expandable. Its simple to add nodes to the network: just tap
into the two wires at any point on the bus. This doesnt require a re-configuration of existing
nodes. Of course, only two pins are needed on the MCU and in the bus connectors. And with
just two connection points per node, a CAN network has a reliability advantage over other
networking schemes that use more wires and connections.
Fourth, more and more MCUs with on-chip CAN functions are becoming available. The same
holds true for tools for debugging CAN networks. Also, the availability of standardized higherlevel protocols helps system designers to build complex control applications efficiently.
Fifth and last, CAN is a mature technology, having been used for over 15 years. During that
time, a substantial body of knowledge has been accumulated about its application, and the
database continues to grow.

Main Features of CAN


Features

Benefits

Has a multiple-master hierarchy

For building intelligent and


redundant systems

Provides transfer rates up to


1 Megabit/sec

For adequate real-time response


in many embedded control
applications

Allows 0-8 bytes of user data


per message

To accommodate diverse design


requirements

Puts multiple transmit or receive


message boxes at each node
and assigns each an identifier

For flexibility in system design

With the five key reasons for using CAN in mind, lets now summarize the main
features of CAN that underlie its growing application popularity.
CAN has a multiple-master hierarchy. This arrangement gives good design flexibility
and allows us to build intelligent and redundant systems.
CAN operates at transfer rates up to 1 Megabit/second (1Mbps) in CAN 2.0B. This
speed provides sufficient data-communication bandwidth for many real-time control
systems.
The CAN protocol allows each CAN data frame to carry up to eight bytes of user data
per message, thus accommodating a wide span of signaling requirements. If
necessary, more data can be transmitted per message using a higher-layer
segmentation protocol.
Each node on a CAN network can have have several buffers or message mailboxes.
On initialization, each mailbox is assigned an identifier that is either unique or is
shared with certain other nodes. Also, each node is individually configured as a
transmitter or receiver. This approach offers considerable flexibility in system design.

Main Features of CAN


Features

Benefits

Eliminates addresses of
transmitting and receiving
nodes in data messages

To save bus bandwidth, simplify


software, and allow simultaneous
transmission of node-to-node and
broadcast messages

Causes receiving nodes to filter


messages based on their
assigned identifiers (IDs)

To simplify node hardware and


software
To permit message prioritization
To allow the hardware to
arbitrate the CAN bus

Automatically retransmits
messages if
corruption occurs

For accurate communication,


even in noisy environments

Provides error detection,


signaling and fault-confinement
measures

To ensure highly reliable network


operation

The Message Frames transmitted on a CAN bus do not contain the addresses of either the
transmitting node or of any intended receiving node. This message-based approach
eliminates data bits that would otherwise use up some of the available bus bandwidth. It also
simplifies the communication software, allows both node-to-node and broadcast messages to
be transmitted simultaneously, and makes it possible to add new nodes to a system without
updating other nodes.
In lieu of transmit and receive node addresses, messages are labeled by an identifier (ID)
assigned to one or more nodes on the network. All nodes receive the message and perform a
filtering operation. That is, each node executes an acceptance test on the identifier to
determine if the message and thus its content is relevant to that particular node. Only
the node(s) for which the message is relevant will process it; all others dont. The identifier
has two more functions, as well. It contains data that specifies the priority of the message,
and it allows the hardware to arbitrate for the bus if several nodes attempt to transmit
simultaneously.
Every node on the bus validates every message. Corrupted messages arent validated, of
course, and that situation triggers automatic retransmissions.
Error detection and error signaling features and fault confinement measures are defined in
the CAN standard. They make the CAN bus very reliable even in noisy environments by
ensuring that the information communicated between nodes is correct and consistent. If a
node is faulty, it will eventually go into a Bus Off mode that shuts it down to prevent it from
disturbing the traffic flow.

Design Factors to Consider


Distance/environment
CAN 2.0B: 1Mbps, up to 40m
CAN 2.0A: 125kbps, up to 500m
Suitable for difficult environments
industrial, automotive, and more

Node A

Node B

CAN Bus

Reliability requirements
Integrated error detection and confinement
Automatic retransmission of corrupted message
Probability of undetected bad message
is <4.7 x 10-11

Number of nodes

Node C

Node D

Node E

Node x

Depends on Physical layer; >100 is feasible

Number of masters
Every node can initiate communication and negotiate for the bus

Net data transfer rate


Up to 577Kbps net at 1Mbps total data transfer rate

Message priority
Message with lowest numerical value identifier wins if two nodes
try to transmit at the same time

A good question now is, What parameters and design requirements define a suitable
application for CAN? The factors listed here are among those to consider.
This serial data communication technology provides communication at up to 1Mbps at
distances up to 40 meters for high-speed CAN 2.0B. (For low-speed CAN 2.0A, the capability
is up to 125kbps at distances up to 500 meters.) Both CAN versions are good choices for
systems that must perform dependably in noisy, difficult environments.
The CAN reliability features previously described reduce the probability of an undetected bad
message to a very low level: less than 4.7 x 10-11. This is virtually a 0% failure rate.
A CAN implementation can have over 100 nodes, or individual MCUs, depending on the
Physical layer of the network.
Because the CAN bus is not controlled by a single master node, all nodes can negotiate for the
bus and send messages. This makes possible intelligent, redundant systems. Also, a defective
network node doesnt disable the network.
The 1Mbps maximum transfer rate that the CAN 2.0B bus delivers includes the overhead
imposed by the network protocol. At that speed, the net transfer rate for message data is
577kbps.
The priority of a CAN message is determined by the numerical value of its identifier. The
message with the lowest numerical value ID in its header has the highest priority. It wins if
another node with lesser priority tries to transmit at the same time.

Data Flow
CAN bus traffic:
The transmitter at a CAN node broadcasts the data frame to all
nodes on the bus.
Nodes configured to accept the data save it
Other nodes do nothing with the data
CAN 2.0A has an 11-bit message identifier and operates at a
maximum frequency of 250kbps.
CAN 2.0B has 11-bit or 29-bit message identifiers and operates
at up to 1Mbps.

Traffic on the CAN bus consists of five types of message frames. They are covered in detail
in the part-2 introductory course. To illustrate how data flows on the bus, lets use a data
frame, which carries actual data.
When a transmitter at a CAN node sends a data frame, it broadcasts that message to all
nodes on the bus. However, only those nodes configured to receive the identifier in that
message will accept and save the data. All other nodes dont do anything with the data.
CAN 2.0A has an 11-bit message identifier and was originally specified to operate at a
maximum frequency of 250kbps. CAN 2.0B has 11-bit or 29-bit message identifiers and can
be used at speeds up to 1Mbps.
This diagram illustrates the basic data flow process. The block on the left represents a
transmitting node; the one in the middle and the one on the right represent receiving nodes.
The middle node has a receiver mailbox set to an identifier that either matches the
transmitted identifier exactly or is within a software-defined identifier range of it, so it
accepts the data frame. It then decides whether to process or discard data, a decision that
is made via software or by using masks and filters.
The node on the right has a receiver mailbox set to a different identifier than the transmitted
one, so it doesnt accept the message. Nevertheless, both receiver nodes (and all other
receiver nodes on the network) subsequently verify and acknowledge the data frame
content to prove successful message transmission. (Incidentally, to further enhance
reliability, the transmitting node checks the message, too.)

Question
Match each CAN item to the most appropriate explanation by dragging
the letters on the left to the correct locations on the right. Click Done
when you are finished.
Must be sent by all receiver
nodes, or message is retransmitted
A 2-wire serial bus communication
method for multiprocessor systems

CAN

Multiple-master hierarchy

Message identifier

Used for addressing, prioritization,


and bus arbitration

Acknowledgment

Enables the design of intelligent and


redundant systems

Done

Reset

Show
Solution

Heres a question for you on some of the aspects of CAN technology we


have discussed so far.

Correct.
CAN is a 2-wire serial bus that provides highly reliable communication
between nodes of multiprocessor embedded control systems. Its multiplemaster hierarchy enables intelligent and redundant designs. The message
identifier specifies the intended receivers for the message, stipulates the
priority of the message, and is used for bus arbitration. Unless all receiver
nodes on the network acknowledge a message, that message will
automatically be re-transmitted.

Physical Interface
Dominant low (voltage) line
Recessive high line
Bus must be terminated
Most common Physical-layer
choice: ISO11898-2

Having covered the basic concept of the CAN data flow, lets examine how a
node physically interfaces to the bus.
The node produces a dominant value by simultaneously driving the C_HI
line high and the C_LO line low. That is, it actively creates a positive
differential voltage between these signals.
A recessive state is created on the CAN bus whenever all nodes on the
network leave the C_HI and C_LO lines in a high-impedance state. That
causes the termination resistors to passively create a zero differential voltage
between these signals.
The CAN bus must be terminated to provide the recessive state and to
eliminate wave reflections at ends of the bus wires. Typical DC bus
terminations are in the 60-Ohm range, and the twisted-pair cables have a
120-Ohm characteristic impedance, which is specified in ISO11898-2. Many
Physical-layer choices are possible, but ISO11898-2 is probably the most
common.
If the application requires that network nodes be electrically isolated from the
CAN bus, this is typically achieved by inserting optical isolators between the
bus transceiver and the MCU. Those isolators will introduce an additional
delay that will almost always limit the maximum bus speed of a CAN 2.0B
network to 500kbps.

10

Physical-Layer Implementation
CAN transceiver: the Renesas
HA13721 ASSP IC:
For in-vehicle applications
ISO11898-2 compliant
High-speed CAN (up to 1Mbps)
Active
Standby modes
Over-temperature detection
Over-current detection
(Vcc-short/GND-short detection)

CANH = C_HI
CANL = C_LO

Optimized EMI performance


Txd, MODE input pins;
3.3V compatible

The CAN Physical-layer implementation is not defined by the Bosch CAN


specification. However, it is defined in the ISO11898-2 standard. Here is an
example of a Physical-layer transceiver that connects to the bus: the
Renesas HA13721 application-specific standard product (ASSP), which is a
CAN transceiver IC designed specifically for in-vehicle use.
The HA13721 transceiver is a standards-compliant high-speed design with
Active and Standby operating modes. It features over-temperature and overcurrent detection to help protect the system, provides good EMI
performance, and has 3.3V-compatible Txd and mode input pins.

11

CAN Bus Data Frame


levels are
TX LO levelsTX
areLow
dominant
(drive bus)dominant (drive bus)

TX High levels are


TX HI levels are
recessive (bus
(bus termination
termination
controls)

recessive
controls)

CANCAN
TXTX
MCU Output to
Transceiver

C_HI CAN HI
Transceiver
Output to Bus
CAN
C_LO LO

CAN uses non-return-to-zero (NRZ) serial data

This captured data frame shows actual bus operation. The top scope trace,
in green, is the signal that drives the transceiver. The other two traces are
the C_HI, in red, and C_LO, in blue, signal lines relative to each other.
Again, a dominant value (CAN_TX = logic low) is created by driving C_HI
high and C_LO low to create a positive differential voltage between them. A
recessive state (CAN_TX = logic high) is created by having all nodes put the
C_HI and C_LO lines in the high-impedance state, so the differential voltage
is zero because no current flows in the bus termination resistors.
Receivers at bus nodes detect a dominant state when a differential voltage
greater than 900mV exists between C_HI and C_LO. They detect a
recessive state when the differential voltage is less than 500mV.
Please notice three things with regard to this scope photo. First, the MCU
transmit pin runs at standard logic levels. Second, there is a 2.5V offset on
the transceiver output to the bus. This is compliant with the ISO11898-2
standard, which allows a common-mode range of -7V to +12V. And third,
CAN uses a non-return-to-zero (NRZ) serial data transmission method a
fact that we will revisit shortly.

12

Message Bit Time: 4 Segments

NOMINAL BIT TIME


SYNC_SEG

PROP_SEG

PHASE_SEG1

SYNC_SEG: Nodes are synchronized within


this phase

PHASE_SEG2

Sample Point

PROP_SEG: Propagation delay compensation


value [ = 2 x (signal propagation time
+ input comparator delay
+ output driver delay)]
PHASE_SEG1 and PHASE_SEG2: Establish correct sampling point

Turning now from voltage to timing issues, it goes without saying that proper
timing is essential to establishing and maintaining good communication on
any data network. To ensure that each message bit on the CAN bus is
sampled at a proper point within the nominal bit time, four phases or values
(parameters) are defined: SYNC_SEG, PROP_SEG, PHASE_SEG1, and
PHASE_SEG2.
The SYNC_SEG portion of the bit time is used to synchronize the various
nodes on the bus. A signal-transition edge is expected to lie within this
phase of the bit-time segment.
The PROP_SEG part of the bit time is used to compensate for the physical
delay times within the network.
The PHASE_SEG1 and PHASE_SEG2 phase-buffer parts of the message
bit time are used to compensate for edge-phase errors. They can be
lengthened or shortened by resynchronization to establish the correct
sampling point.
The values for the four bit-time parameters typically are defined in the toplevel specification for a network. They are set by taking into account factors
such as wiring length, bandwidth requirement, operating environment, etc.
Its important to remember that the timing parameter values must be the
same for all nodes.

13

Maintaining Synchronization
Bit stuffing is applied as needed to keep the bus
synchronized:
Too many consecutive dominant or recessive bits
cause the transmitting node to insert a bit of the
opposite polarity
Resulting signal edge is used to establish timing
synchronization at all nodes on the bus
The bit is inserted whenever a sequence of five bits
with the same polarity occurs

Of course, its essential that timing synchronization always be maintained at


all network nodes. Many network communication methods mandate that a
signal line return to the zero state after each bit is transmitted. The resulting
transitions are used to keep the serial data synchronized. But as mentioned
before, CAN uses an NRZ serial data transmission method, so a string of
repeating 1s or 0s contains no state transitions. Such strings, if they were
long enough, might cause a loss of synchronization due to variations in the
frequencies of the clocks at different nodes.

14

Maintaining Synchronization

Stuffed bit

For this reason, CAN uses bit stuffing to maintain synchronization. Bit
stuffing means that when too many dominant or recessive bits are sent
consecutively to keep the bus synchronized, the transmitting node inserts an
opposite-polarity bit. The resulting signal edge is used to establish timing
synchronization at all nodes on the bus. Specifically, CAN requires that bit
stuffing be applied after there is a sequence of five bits with the same
polarity.

15

Question
Which of these statements correctly describe voltage and
timing aspects of CAN bus operation? Select all that apply
and then click Done.
A dominant value (positive differential voltage >900 mV) is
created by driving the C_HI line high and the C_LO line low.
Mandatory CAN bus termination resistors create a recessive
value when all bus nodes go to a high-impedance state.
Because CAN uses NRZ serial data, synchronization
between nodes is maintained automatically.
The PROP_SEG portion of the bit time is used to
compensate for physical delays within the network.

Done

Heres another question for you. This one covers CAN bus voltages and
timing.

Correct.
A dominant value that is, a positive differential voltage greater than 900
mV is created by driving the C_HI line high and the C_LO line low. CAN
bus termination resistors must be used; they create a recessive value when
all nodes on the bus go to a high-impedance state. CAN uses NRZ serial
data, so bit stuffing is needed to maintain synchronization whenever five
consecutive bits of the same polarity occur. The PROP_SEG portion of the
bit time is used to compensate for physical delays within the network.

16

CAN in the OSI Model


Higher-Layer Protocols
Data
Data
Host
Layers

Data
Segments
Packets
Media
Layers

Frames
Bits

Application

CAN Features
Data Link

Network Process to Application

LLC

Presentation

Acceptance Filtering
Overload Notification
Recovery Management

Data Representation and


Encryption

Session

MAC

Interhost Communication

Data Encapsulation/Decapsulation
Frame Coding (Stuffing, Destuffing)
Medium Access Management
Error Detection
Error Signaling
Acknowledgment
Serialization / Deserialization

Transport
End-to-End Connections and
Reliability

Network
Path Determination and IP
(Logical Addressing)

Data Link

Physical

MAC and LLC


(Physical Addressing)

Bit Encoding/Decoding
Bit Timing
Synchronization

Physical
Media, Signal and Binary
Transmission

Driver/Receiver Characteristics

ISO 11898

Mouse over any of the blocks containing fine print to learn more.

Up until now, we have talked about the Physical layer of the network without
explaining what it is. Lets briefly address that deficiency now.
The Physical layer is part of the 7-layer Open Systems Interconnect (OSI), a
standard definition or reference model for how messages should be
transmitted in a network.
The bottom three layers in the OSI communication model Physical, Data
Link and Network are the Media layers. The top four Transport,
Session, Presentation and Application are the Host layers.
CAN by itself is only concerned with the lowest layers of the model. That is,
ISO11898 defines the Data Link and Physical layers, which are shown here
in red. Additionally, the CAN 2.0B specification covers a portion of the
Transport layer: the retransmission/retry control function. You can learn
more by rolling your mouse pointer over any of the blocks containing fine
print.

17

Higher-layer CAN Protocols


Automotive
Incompatible OEM
GM (LAN3.0)
Daimler-Chrysler
Ford
Toyota, etc.

DeviceNet

Industrial

Other
NMEA2000
(marine)

CAN Open

CANaerospace
(avionics)

Proprietary

SAE J1939
(heavy trucks)
ISO11783
(agricultural vehicles)

Proprietary

CAN Interface

Circuits or subsystems at CAN nodes generally have software that uses protocols that
implement the upper 5 levels of the 7-layer OSI model. In the automotive market, vehicle
manufacturers use proprietary CAN protocols. In the industrial market, the most commonly
used standard protocols are CAN Open and DeviceNet.
CAN Open was developed as a standardized embedded network with highly flexible
configuration capabilities. Now it is used in many fields, such as medical equipment, off-road
vehicles, public transportation, building automation, etc. The CAN Open specifications cover
the application layer and communication profile. They also provide a framework for
programmable devices; recommendations for cables, connectors and SI units; and prefix
representation.
DeviceNet is an open low-level network protocol that provides connections between simple
industrial devices such as sensors and actuators, and higher-level devices such as
embedded controllers and computers. The DeviceNet network is flexible and works with
products from multiple vendors. It uses the proven Common Industrial Protocol (CIP) to
provide control, configure, and data-collection capabilities for industrial devices.
Other standard CAN protocols include NEMA2000 for marine applications, CANaerospace
for aircraft systems, SAE J1939 for heavy trucks and ISO11783 for agricultural vehicles.
Incidentally, most of the protocols discussed here dont implement several of the
intermediate levels of the OSI model because it isnt necessary to do so.
The availability of these standardized higher-level protocols helps system designers to build
complex control applications efficiently. The combination of standard off-the-shelf CAN
hardware and standard but customizable protocol software makes system development time
more accountable and accurate.
Before wrapping up this introductory course on CAN, we provide a two-page glossary of key
terms used in the technology. Click Glossary to examine these definitions.

18

Glossary

Advanced CAN: CAN peripheral with varying numbers of buffers configurable for transmit/receive. Receive
buffers have hardware filtering on at least mask/match identifier content.
Basic CAN: CAN peripheral with no hardware filtering. Typically two receive buffers act as a FIFO and
accept all bus traffic. Usually one transmit buffer.
Bit Time: Nominal time of one bit on the CAN bus. Made up of multiple segments that allow each node to
synchronize to the received bus traffic. All nodes on a bus must be configured to the same (nominal) bit time.
CAN: Controller Area Network.
CAN 2.0B: Version 2.0 was the last version of CAN defined by Bosch. Part B added extended identifiers and
the idea of hardware filtering.
CIA: CAN in Automation. Group controlling the CANOpen protocol.
CANOpen: Multi-area communication protocol using CAN.
CRC: Cyclic Redundancy Check.
DeviceNet: Industrial communication protocol using CAN.
Dominant/Recessive: Dominant bits on Physical layer can override recessive bits.
Filters: Hardware in the CAN peripheral that can mask/match bits within the identifier field. Used to
determine whether or not to route bus data to a mailbox.
GM LAN 3.0: GM protocol. Encompasses all GM serial protocols.
Identifier: Frame field that indicates the message content. This field also is used to arbitrate the message
priority on the bus. A lower ID has a higher priority.
Standard Format: Frames use an 11-bit identifier.
Extended Format: Frames use a 29-bit ID.
ISO 11898: ISO standardized version of CAN.
Mailbox: CAN hardware buffer that can be used to transmit or receive data. Most FullCAN implementations
have at least 16 mailboxes.
ODVA: Open DeviceNet Vendor Association. Group controlling DeviceNet protocol.
Time Quanta: Smallest time unit used by CAN. Multiple time quanta make up the segments of a bit time.
TT CAN: Time Triggered CAN. More deterministic form of CAN. Assigns time slots when nodes may
transmit.
FlexRay: Next-generation automotive network. Time slots on the bus provide more deterministic behavior.
Vector-CanTech: Supplier of the majority of CAN software drivers and tools for ECUs of North American and
European automobiles.

Reference information for Glossary button on previous page

19

Question
Is the following statement true or false? Click Done when you are finished.
Basically, CAN is concerned with the lowest layers of the OSI model,
but CAN 2.0B also implements part of the transport layer.
True
False

Done

Consider this question regarding the OSI model.

Correct.
Basically, CAN implements only the lowest layers of the OSI model, the
Data Link and Physical layers. One exception to this rule is the CAN 2.0B
specification, which also implements the retransmission/retry control function
of the Transport layer.

20

Course Summary
CAN description, applications, features/benefits
Design factors/parameters
Data frame and data flow
Timing issues
Physical interface, OSI model, and higher-level protocols
Glossary

This concludes our Part-1 CAN Basics course. You learned what CAN is,
why its important, and where its used most often. You also discovered
key CAN features, benefits and design factors, then gained insight into
data flow, the Physical layer and bus voltages and timing issues. Finally,
you learned how CAN fits into the OSI model and read definitions of key
terms.
The Part-2 CAN Basics course covers Message Frames, bus errors and
network implementation issues. Other courses in this series on CAN
technology discuss the API for Renesas microcontroller CAN peripherals
and provide specific design information for designing CAN-based
multiprocessor systems.
Thank you for your interest in CAN technology and for using the tutorial
area of the Renesas Interactive website. We now invite you to take
additional courses that are available and to use the many other free
resources offered here.

21

Вам также может понравиться