Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

14 Can PDF

Download as pdf or txt
Download as pdf or txt
You are on page 1of 40

14

Controller Area
Network (CAN)
Distributed Embedded Systems
Philip Koopman
October 19, 2015

Significant material (CAN pictures) drawn from


a presentation by Siemens Corp. “CANPRES 2.0, Oct 1998”

© Copyright 2000-2015, Philip Koopman


Where Are We Now?
 Where we’ve been:
• Protocol Overview

 Where we’re going today:


• CAN -- an important embedded
protocol
• Primarily automotive, but used in
many places

 Where we’re going next:


• CAN performance
• Other protocols

 REMINDER – look at lessons


learned slides for ideas on how to do
better on second half of project!
2
Preview
 CAN – important automotive protocol
• Physical layer – built on bit dominance
• Protocol layer – binary countdown
• Message filtering layer (with add-on protocols)

 Keep an eye out for:


• Message prioritization
• How “small” nodes can be kept from overloading with received messages
• Tradeoffs

3
Before CAN – Individual Connections

[Siemens] 4
With CAN

[Siemens] 5
CAN Is Central To Automotive Networks

[Leen02]
6
SAE Message Classes
 Fast tends to correlate with critical control
• But, this is not always true; just often true

(Often LIN or J1850)

[Siemens] 7
CAN & the Protocol Layers
 CAN only standardizes the lower layers
 Other high-level protocols are used for application layer
• User defined
• Other standards

• We’ll see one possibility


at the end of this lecture

[Siemens] 8
Remember This? Binary Countdown
Nodes Attempt Recessive
To Send: 1 0 1
Drops out of
Node 5:
5 competition
1 0 0
Node 4
4:
1 0 0
Network Sees:

 Operation
• Each node is assigned a unique identification number
• All nodes wishing to transmit compete for the channel by transmitting a binary
signal based on their identification value
• A node drops out the competition if it detects a dominant state while
transmitting a passive state
• Thus, the node with the lowest identification value wins

 Examples
• CAN – 500 Kbps or 1 Mbps
• SAE J1850 – pretty much same as CAN, except slower (around 10 Kbps)
9
CAN – Bit Dominance In More Detail
 CAN uses the idea of recessive and dominant bits
• Wired “OR” design
• Bus floats high unless a transmitter pulls it down (dominant)
• (Other bus wire in differential transmission floats low and transmitter pulls up)
 High is “recessive” value
• Sending a “1” can’t override the value seen on the bus
 Low is “dominant” value
• Sending a “0” forces the bus low no matter what another node is sending

ON OFF OFF

[Siemens]
10
Example: Binary Countdown (highest bit first)
Value seen
on bus
0 0 0 1 0 0 0 Node 8 message

Values that each node attempts to transmit:


Node 8
ID=0001000 0 0 0 1 0 0 0 8 has the bus

Node 9
ID=0001001 0 0 0 1 0 0 1
Node 10
ID=0001010 0 0 0 1 0 1 9 drops out

Node 12
ID=0001100 0 0 0 1 1 10 drops out

Node 17
ID=0010001 0 0 1 12 drops out

Time
17 drops out (stops competing for the bus) 11
Physical Layer Possibilities
 MUST support bit dominance
• Specifically rules out transformer coupling for high-noise applications
• Differential driver used
– Voltage across wires is dominant; high impedance (0V differential) is recessive
– Opto-isolators are commonly used as well

[Siemens] 12
Non-Return to Zero (NRZ) Encoding
 Send a Zero as LO; send One as HI
• Worst case can have all zero or all one in a message – no edges in data
• Simplest solution is to limit data length to perhaps 8 bits
– SYNC and END are opposite values, guaranteeing two edges per message
– This is the technique commonly used on computer serial ports / UARTs
• Bandwidth is one edge per bit
– Same bandwidth as Miller encoding, but no guarantee of frequent edges
Simple NRZ Bit Encoding

SYMBOL SYMBOL SYMBOL SYMBOL


ONE ZERO SYNC END

H L L H

PHYSICAL PHYSICAL PHYSICAL PHYSICAL


BIT BIT BIT BIT

Simple NRZ Encoding Example: 1101 0001

END SYNC ONE ONE ZERO ONE ZERO ZERO ZERO ONE END SYNC …
PREVIOUS SUBSEQUENT
MESSAGE MESSAGE
L H H L H L L L H H
13
Bit Stuffing To Add Edges To NRZ Encoding
 Long NRZ messages cause problems in receivers
• Clock drift means that if there are no edges, receivers lose track of bits
• Periodic edges allow receiver to resynchronize to sender clock
 Solution: add “stuff bits”
• Stuff bits are extra bits added to force transitions regardless of data
• Typical approach: add an opposite-valued stuff bit after every 5 identical bits
• In best case you don’t need stuff bits – they only are needed for runs of values
BIT STUFF IDEA:
SIMPLE NRZ ENCODING OF: 1111 1111 1111 0000 0000 0000:
ZERO
ZERO
ZERO
ZERO
ZERO
ZERO
ZERO
ZERO
ZERO
ZERO
ZERO
ZERO
ONE
ONE
ONE
ONE
ONE
ONE
ONE
ONE
ONE
ONE
ONE
ONE

H H H H H H H H H H H H L L L L L L L L L L L L
STUFF

STUFF

STUFF

STUFF
ZERO
ZERO
ZERO
ZERO
ZERO

ZERO
ZERO
ZERO
ZERO
ZERO

ZERO
ZERO
ONE
ONE
ONE
ONE
ONE

ONE
ONE
ONE
ONE
ONE

ONE
ONE

H H H H H L H H H H H L H H L L L L L H L L L L L H L L
BIT-STUFFED NRZ ENCODING OF: 1111 1111 1111 0000 0000 0000: 14
NRZ Encoding Error Susceptibility
 A single inverted physical bit is undetectable with Simple NRZ
• High efficiency comes at price of poor error detection
ZERO ONE
END SYNC ONE
X ONE ZERO
X ONE ZERO ZERO ZERO ONE END SYNC …
PREVIOUS SUBSEQUENT
MESSAGE MESSAGE
L XH H L
X H L L L H H
L H

• (Can be detected via CRC sometimes; but CRCs have limitations)

 Bit stuffing error detection in general case:


• Improves error detection if stuffing rule is violated
• Any six identical data bits in a row is an stuffing error
• But, there is a subtle problem with bit stuffing…

15
Cascaded Bit Stuffing Errors
 Bit inversions in just the wrong place can confuse bit stuffing logic
• Worst errors occur in pairs that create and then break runs of bits
• Data bit is converted to stuff bit; stuff bit to data bit
• Net effect is same message length BUT, it shifts intervening data bits
• CAN has this problem; can cause 2-bit error to escape CRC detection!
Cascaded bit stuff error example:

TRANSMITTED LOGICAL BITS: 1101 0101 0111 1111

STUFF
ZERO

ZERO

ZERO

ZERO
ONE
ONE

ONE

ONE

ONE

ONE
ONE
ONE
ONE
ONE

ONE
ONE
SYNC END

L L L L L L H H H L H L H L H L H H H H H L H H L H H H H H H
PHYSICAL BIT
INVERSIONS
STUFF

ZERO
ZERO

ZERO

ZERO
ONE
ONE
ONE
ONE

ONE

ONE

ONE
ONE
ONE

ONE

ONE
ONE
SYNC END

L L L L L L H H H H H L H L H L H H H L H L H H L H H H H H H

RECEIVED LOGICAL BITS: 1111 1010 1110 10 11 16


General CAN Message Format

SYNC HEADER DATA ERROR DETECTION END

 Header
• Application can set any desired value in 11- or 29-bit header
• Global priority information (which message gets on bus first?)
• Header often contains source, destination, and message ID

 Data
• Application- or high-level-standard defined data fields
• 0 to 8 bytes of data for CAN

 Error detection
• Detects corrupted data (uses a 15-bit CRC):
– All 15-bit or shorter burst errors (groups of flipped bits clumped together)
– All 5-bit errors regardless of where they occur …
… except bit stuffing problem reduces this to all 1-bit errors
17
Two Sizes of CAN Arbitration Fields

[Bosch] 18
CAN Message Fields
 SOF – Start of frame (SYNC symbol)
• Single dominant bit
 Arbitration field – binary countdown priority value; set by application
• Also an RTR (remote transmission) field for atomic transactions; seldom used
• SRR is a dummy bit to let standard format RTR messages win arbitration
 Control field
• 4-bit data length (number of bytes in data field); valid values: 0 .. 8
• 1 bit specifies standard or extended format; 1 bit unused
 Data field
• 0 to 8 bytes
 CRC field
• 15-bit CRC, followed by one recessive delimiter bit
 Ack field
• If message received OK, assert as dominant bit (at least one node received)
 END of frame delimiter
• Seven recessive bits mark end of frame (phase violation for bit stuff pattern) 19
Error Frame Messages
 Error frame alerts transmitter if message garbled at some receivers
• Sent if bit stuff violation detected or CRC error detected
• Error flag is six dominant bits in a row – guaranteed to violate bit stuffing rules
– (Unless the Error Frame itself suffers a bit error)
• If transmitter sees that it has been pre-empted by an error frame, it attempts
retransmission
– Note – this is a source of nondeterminism in protocol – timing varies depending on
errors encountered!

[Siemens] 20
CAN vs. FlexRay Length Field Corruptions
 CAN does not protect length field against ONE-BIT errors
• Corrupted length field will point to wrong location for CRC!
– One bit error in length field circumvents HD=6 CRC
– Could get unlucky and have a match

ID LEN DATA CRC Original Message

ID LEN DATA CRC CRC Corrupted LEN

 FlexRay solves this with a header CRC to protect Length

Source: FlexRay Standard, 2004

21
http://betterembsw.blogspot.com/2012/02
Other CAN Issues /can-protocol-vulnerabilities.html

 CAN advertises “exactly once” delivery semantics


• A message corrupted only in some places is retransmitted…
… and received more than once by some nodes
[Rufino 1998]
 “Stuck at zero” (dominant) transmitter output locks up network
 CAN retry:
• “Error frame” scheme causes re-transmit
and ALSO,
• Node monitors network and looks for data sent == data received
– If no match, assumes corruption and tries again
• But what if the transmitter is what is broken?
– CAN node can lock up the network with retries [Perez 2003]

 In general, CAN unsuitable for highly critical applications


• That’s one reason we have FlexRay (and TTP) protocols
• This is news to some embedded folks (e.g., ARINC 825 aviation standard)
22
CAN (SAE J1939) Example: Caterpillar 797
797 System
VIMS - PC ET Service Tool

VIMS II
Chassis Control
(ABL2M)
(ABL2C)

Braking/Cooling
(ABL2C)
ADEM II
Master
Xmsn/TC
(ABL2C)

ADEM II ADEM II
Slave 1 Slave 2 RAC/CLIM
(68K Module) Tire
Monitor

CAT Datalink

CAN SAE J1939 Datalink + 195 sensors and actuators


797sys.vsd
6-18-98
dab/jwf
Warning: All paper copies of this document are uncontrolled
+ wireless data link [Slide courtesy of Caterpillar Inc.] 23
ADEM II Engine Control
Coolant Flow
Switch Prelube Relay
ADEM-II-6X
138-3672 3E-5239
Master
Ground Level 115-3055
Shutdown Switch
4D-1836

User Shutdown
Switch

Throttle Bypass
Switch
ADEM Slave #1 ADEM Slave #2
126-0236
132-8900 132-8900
Manual Ether Aid
Switch
3E-7176
Oil Renewal
Solenoid
Throttle Sensor 142-7363
3E-7700
Wastegate
Speed/Timing Solenoid
Sensor 109-4591
129-6628
Injector Solenoids
137-9881
CAN Data Link (future) (QTY. 12)

CAT Data Link

ATA Data Link

LH Turbo Exh. Oil Press. Sensor LH Turbo Exh. Oil Press. Sensor
Temp. Sensor (Unfiltered) Temp. Sensor (Unfiltered)
109-4367 143-9695 109-4367 143-9695

Atmospheric RH Turbo Exh. Atmospheric RH Turbo Exh.


Pressure Sensor Temp. Sensor Pressure Sensor Temp. Sensor
143-9696 109-4367 143-9696 109-4367
Speed/Timing Speed/Timing
RH Turbo Inlet RH Turbo Inlet
Sensor Sensor
Pressure Sensor Pressure Sensor
129-6628 129-6628
143-9696 143-9696
Fuel Pressure Oil Press. Sensor Fuel Pressure Oil Press. Sensor
Sensor (Filtered) Sensor (Filtered)
XX-XXXX 143-9695 XX-XXXX 143-9695

Low Oil Level Coolant Temp. Low Oil Level Coolant Temp.
Sensor Sensor Sensor Sensor
123-2993 102-2240 123-2993 102-2240
Very Low Oil After Cooler Very Low Oil After Cooler
Level Sensor Temp. Sensor Level Sensor Temp. Sensor
123-2993 102-2240 123-2993 102-2240
Turbo Outlet Crankcase Turbo Outlet Crankcase
Pressure Sensor Pressure Sensor Pressure Sensor Pressure Sensor
143-9694 143-9696 143-9694 143-9696

Start Aid Pull-in Start Aid Pull-in


Relay CAT Data Link Relay CAT Data Link
3E-5239 CAN Data Link 3E-5239 CAN Data Link
Start Aid Hold (future) Start Aid Hold (future)
Relay ATA Data Link Relay ATA Data Link
3E-5239 Timing 3E-5239 Timing
adem.vsd
Calibration Calibration
6-18-98
dab/jwf

[Slide courtesy of Caterpillar Inc.] 24


Arbitration Limits Network Size
 Need 2*tpd per bit maximum speed

[Siemens] 25
“Big” & “Small” Nodes
 Some nodes can handle a lot of messages
• Many message mailboxes/filters
• Fast processor

 Some small nodes have limited capacity


• One or two mailboxes/filters
• Slow processor

 System designer has to prevent message over-run via one of:


• Dedicated mailbox per message (hardware ensures no data lost)
• If mailbox shared, ensure messages to slow processors are spaced apart
– Must be infrequent
– Must ALSO not be clumped closer than receiver response time
– This ends up being a constraint for real time scheduling (a later lecture)

26
Generic CAN Network Implementation
 Signals usually sent differentially – CAN_H and CAN_L

[Siemens] 27
Example CAN Microcontrollers
 Motorola 68HC05 Family
• 11-bit headers; 1 Tx buffers; 2 Rx message buffers; 8-bit accept mask
• 8-bit CPU; up to 32 KB on-chip ROM; 28- or 64-pin housing
• (Also 68HC08 with 29-bit support and more buffers)

 Motorola 68HC912 Family


• 11- & 29-bit headers; 3 Tx buffers; 2 Rx message buffers; 2 accept masks
• 16-bit CPU; up to 128 KB on-chip Flash; 80- or 112-pin housing

 Motorola 6837X Family


• 11- & 29-bit headers; 16 Tx/Rx buffers; 16 accept masks
• 32-bit CPU; 256 KB on-chip Flash

 Many other companies support CAN of course – these are just


examples
28
Basic CAN Controller (avoid this one if possible)
 “Cheap” node
• Could get over-run with messages even if it didn’t need them

[Siemens] 29
Full CAN Controller
 Hardware message filters sort & filter messages without interrupting
CPU
• Message object holds most recent message fo that type – not a queue!

[Siemens] 30
Mask Registers
 Used to set up message filters
• Mask register selects bits to examine
• Object Arbitration register selects bits that must match to be accepted
• Map multiple messages into each message object “mailbox”

[Siemens] 31
Mask Register Example
 Mask Register: 110 1110 1011
 Message Object Arbitration: 100 0100 0001
 Effective Match Value: 10* 010* 0*01

 Matches these message IDs: 100 0100 0001


100 0100 0101
100 0101 0001
100 0101 0101
101 0100 0001
101 0100 0101
101 0101 0001
101 0101 0101

 More likely, you mask a few bits next to each other


• See DeviceNet later in lecture
32
DeviceNet
 One of several higher-level protocols
• Based on top of CAN
• Used for industrial control (valves, motor starters, display panels, …)
– Caterpillar is a member of ODVA as well (Open DeviceNet Vendors Assn.), but for
factory automation.

 Basic ideas:
• CAN is used in high volumes = cheaper network chips than competitors
• Use structured approach to message formats to standardize operation

 Does NOT standardize specific message contents


• But it does specify a hierarchy of message ID formats

33
DeviceNet Message ID Scheme
 Each node on network “owns” a source node or message ID (or both)
Message Identifier Bits
10 9 8 7 6 5 4 3 2 1 0 Hex Range Identity Usage

0 Message ID Source Node # 000 - 3ff Group 1


1 0 Source Node # Msg ID 400 - 5ff Group 2
1 1 Msg ID (0..6) Source Node # 600 - 7bf Group 3
1 1 1 1 1 Message ID (0..2f) 7c0 - 7ef Group 4
1 1 1 1 1 1 1 X X X X 7f0 - 7ff Invalid

 Use message filters to only listen to messages you care about


• E.g., Use message object arbitration to subscribe to a particular message ID
• E.g., Use mask object to accept that message ID from any source node #
• Elevator example: message ID is button press; source node # tells which button
– Single receiver mailbox then holds most recently received button press message
– Message must be processed before next such message is received! 34
DeviceNet Group Strategy
 Group 1
• Prioritized by Message ID / Node number
• High priority messages with fairness to nodes

 Group 2
• Prioritized by Node number / Message ID
• Gives nodes priority

 Group 3
• Essentially same as Group 1, but allows Group 2 to have higher priority

 Group 4
• Global housekeeping messages / must be unique in system (no node number)

35
Other Approaches Are Possible
 And, you can invent your own too…

 Variations include:
• Automatic assignment of node numbers (include hot-swap)
• Automatic assignment of message numbers (include hot-swap)
• Mixes of node-based vs. message-ID based headers

 Can you have two transmitters using the same exact header field?
• No – that would produce a bus conflict
• Unless you have middleware that ensures only one node can transmit at a time
– For example use a low priority message as a token to emulate token-passing

 Higher level protocols define message types


• For example, J1939 defines message ID meanings, mostly for trucks and buses

36
CAN Workloads – Spreadsheets
 “SAE Standard Workload” (53 messages) V/C = Vehicle Controller [Tindell]

37
CAN Tradeoffs
 Advantages
• High throughput under light loads
• Local and global prioritization possible
• Arbitration is part of the message - low overhead

 Disadvantages
• Requires bit dominance (can’t be used with transformer coupling)
• Propagation delay limits bus length (2 tpd bit length)
• Unfair access - node with a high priority can "hog" the network
– Can be reduced in severity with Message + Node # prioritization
– Can, in principle, use a bus guardian to limit duty cycle of each node
• Poor latency for low priority nodes
– Starvation is possible

 Optimized for:
• Moderately large number of message types
• Arbitration overhead is constant
• Global prioritization (but limited mechanisms for fairness)
38
[Electronic Design; Jan 8, 2001, pg. 66] 39
Review
 Controller Area Network
• Binary-countdown arbitration
• Standard used in automotive & industrial control

 CAN Tradeoffs
• Good at global priority (but difficult to be “fair”)
• Efficient use of bandwidth
• Requires bit-dominance in physical layer
• Message filters are required to keep small nodes from being overloaded
– Only works if small node can read data before next data in that mailbox arrives

40

You might also like