CAN Specification 2.0, Part B page 1
CAN in Automation, Am Weichselgarten 26, D-91058 Erlangen
PART B
CAN Specification 2.0, Part B page 2
CAN in Automation, Am Weichselgarten 26, D-91058 Erlangen
1 INTRODUCTION ................................................................................................................3
2 BASIC CONCEPTS ..............................................................................................................5
3 MESSAGE TRANSFER .....................................................................................................11
3.1 Frame Formats ..................................................................................................................11
3.2 Frame Types.....................................................................................................................11
3.2.1 DATA FRAME.............................................................................................................11
3.2.2 REMOTE FRAME .......................................................................................................18
3.2.3 ERROR FRAME...........................................................................................................19
3.2.4 OVERLOAD FRAME ..................................................................................................20
3.2.5 INTERFRAME SPACING...........................................................................................22
3.3 Conformance with regard to Frame Formats.....................................................................24
3.4 Definition of TRANSMITTER / RECEIVER..................................................................24
4 MESSAGE FILTERING.....................................................................................................25
5 MESSAGE VALIDATION.................................................................................................26
6 CODING..............................................................................................................................27
7 ERROR HANDLING..........................................................................................................28
7.1 Error Detection..................................................................................................................28
7.2 Error Signalling ..................................................................................................................29
8 FAULT CONFINEMENT..................................................................................................30
9 OSCILLATOR TOLERANCE............................................................................................33
10 BIT TIMING REQUIREMENTS ....................................................................................34
CAN Specification 2.0, Part B page 3
CAN in Automation, Am Weichselgarten 26, D-91058 Erlangen
1 INTRODUCTION
The Controller Area Network (CAN) is a serial communications protocol which efficiently
supports distributed realtime control with a very high level of security.
Its domain of application ranges from high speed networks to low cost multiplex wiring.
In automotive electronics, engine control units, sensors, anti-skid-systems, etc. are connected
using CAN with bitrates up to 1 Mbit/s. At the same time it is cost effective to build into
vehicle body electronics, e.g. lamp clusters, electric windows etc. to replace the wiring har-
ness otherwise required.
The intention of this specification is to achieve compatibility between any two CAN imple-
mentations. Compatibility, however, has different aspects regarding e.g. electrical features
and the interpretation of data to be transferred. To achieve design transparency and imple-
mentation flexibility CAN has been subdivided into different layers according to the ISO/OSI
Reference Model:
· the Data Link Layer
- the Logical Link Control (LLC) sublayer
- the Medium Access Control (MAC) sublayer
· the Physical Layer
Note that in previous versions of the CAN Specification the services and functions of the
LLC and MAC sublayers of the Data Link Layer had been described in layers denoted as
'object layer' and 'transfer layer'. The scope of the LLC sublayer is
· to provide services for data transfer and for remote data request,
· to decide which messages received by the LLC sublayer are actually to be accepted,
· to provide means for recovery management and overload notifications.
There is much freedom in defining object handling. The scope of the MAC sublayer mainly is
the transfer protocol, i.e. controlling the Framing, performing Arbitration, Error, Checking, Error
Signalling and Fault Confinement. Within the MAC sublayer it is decided whether the bus is
free for starting a new transmission or whether a reception is just starting. Also some general
features of the bit timing are regarded as part of the MAC sublayer. It is in the nature of the
MAC sublayer that there is no freedom for modifications.
CAN Specification 2.0, Part B page 4
CAN in Automation, Am Weichselgarten 26, D-91058 Erlangen
The scope of the physical layer is the actual transfer of the bits between the different nodes
with respect to all electrical properties. Within one network the physical layer, of course, has
to be the same for all nodes. There may be, however, much freedom in selecting a physical
layer.
The scope of this specification is to define the MAC sublayer and a small part of the LLC
sublayer of the Data Link Layer and to describe the consequences of the CAN protocol on
the surrounding layers.
CAN Specification 2.0, Part B page 5
CAN in Automation, Am Weichselgarten 26, D-91058 Erlangen
2 BASIC CONCEPTS
CAN has the following properties
· prioritization of messages
· guarantee of latency times
· configuration flexibility
· multicast reception with time synchronization
· system wide data consistency
· multimaster
· error detection and error signalling
· automatic retransmission of corrupted messages as soon as the bus is idle again.
· distinction between temporary errors and permanent failures of nodes and autonomous
switching off of defect nodes.
Layered Architecture of CAN according to the OSI Reference Model
· The Physical Layer defines how signals are actually transmitted and therefore deals with
the description of Bit Timing , Bit Encoding, and Synchronization. Within this
specification the Driver/Receiver Characteristics of the Physical Layer are not defined so
as to allow trans-mission medium and signal level implementations to be optimized for
their application.
· The MAC sublayer represents the kernel of the CAN protocol. It presents messages
received from the LLC sublayer and accepts messages to be transmitted to the LLC
sublayer. The MAC sublayer is responsible for Message Framing, Arbitration,
Acknowledgement, Error Detection and Signalling. The MAC sublayer are supervised by
a management entity called Fault Confinement which is self-checking mechanism for
distinguishing short disturbances from permanent failures.
· The LLC sublayer is concerned with Message Filtering, Overload Notification and
Recovery Management.
CAN Specification 2.0, Part B page 6
CAN in Automation, Am Weichselgarten 26, D-91058 Erlangen
LLC = Logical Link Control
MAC = Medium Access Control
Data Link Layer
LLC Supervisor
Acceptance Filtering
Overload Notification
Recovery Management
MAC
Data Encapsulation
/Decapsulation
Frame Coding
(Stuffing, Destuffing) Fault
Medium Access Management Confinement
Error Detection
Error Signalling
Acknowledgement
Serialization / Deserialization
Physical Layer
Bit Encoding/Decoding
Bit Timing Bus Failure
Synchronization Management
Driver/Receiver Characteristics
CAN Specification 2.0, Part B page 7
CAN in Automation, Am Weichselgarten 26, D-91058 Erlangen
The scope of this specification is to define the Data Link Layer and the consequences of the
CAN protocol on the surrounding layers.
Messages
Information on the bus is sent in fixed format messages of different but limited length (see
section 3: Message Transfer). When the bus is free any connected unit may start to transmit
a new message.
Information Routing
In CAN systems a CAN node does not make use of any information about the system
configuration (e.g. station addresses). This has several important consequences.
System Flexibility: Nodes can be added to the CAN network without requiring any
change in the software or hardware of any node and application layer.
Message Routing: The content of a message is named by an IDENTIFIER. The
IDENTI-FIER does not indicate the destination of the message, but describes the
meaning of the data, so that all nodes in the network are able to decide by Message
Filtering whether the data is to be acted upon by them or not.
Multicast: As a consequence of the concept of Message Filtering any number of nodes
can receive and simultaneously act upon the same message.
Data Consistency: Within a CAN network it is guaranteed that a message is
simultaneously accepted either by all nodes or by no node. Thus data consistency of a
system is achieved by the concepts of multicast and by error handling.
Bit rate
The speed of CAN may be different in different systems. However, in a given system the
bit-rate is uniform and fixed.
Priorities
The IDENTIFIER defines a static message priority during bus access.
CAN Specification 2.0, Part B page 8
CAN in Automation, Am Weichselgarten 26, D-91058 Erlangen
Remote Data Request
By sending a REMOTE FRAME a node requiring data may request another node to send the
corresponding DATA FRAME. The DATA FRAME and the corresponding REMOTE
FRAME are named by the same IDENTIFIER.
Multimaster
When the bus is free any unit may start to transmit a message. The unit with the message of
highest priority to be transmitted gains bus access.
Arbitration
Whenever the bus is free, any unit may start to transmit a message. If 2 or more units start
transmitting messages at the same time, the bus access conflict is resolved by bitwise arbitra-
tion using the IDENTIFIER. The mechanism of arbitration guarantees that neither informa-
tion nor time is lost. If a DATA FRAME and a REMOTE FRAME with the same IDENTI-
FIER are initiated at the same time, the DATA FRAME prevails over the REMOTE
FRAME. During arbitration every transmitter compares the level of the bit transmitted with
the level that is monitored on the bus. If these levels are equal the unit may continue to send.
When a 'recessive' level is sent and a 'dominant' level is monitored (see Bus Values), the unit
has lost arbitration and must withdraw without sending one more bit.
Safety
In order to achieve the utmost safety of data transfer, powerful measures for error detection,
signalling and self-checking are implemented in every CAN node.
Error Detection
For detecting errors the following measures have been taken:
- Monitoring (transmitters compare the bit levels to be transmitted with the bit levels
de-
tected on the bus)
- Cyclic Redundancy Check
- Bit Stuffing
- Message Frame Check
Performance of Error Detection
The error detection mechanisms have the following properties:
- all global errors are detected.
- all local errors at transmitters are detected.
- up to 5 randomly distributed errors in a message are detected.
- burst errors of length less than 15 in a message are detected.
CAN Specification 2.0, Part B page 9
CAN in Automation, Am Weichselgarten 26, D-91058 Erlangen
- errors of any odd number in a message are detected.
Total residual error probability for undetected corrupted messages: less than
message error rate á 4.7 á10 -11.
Error Signalling and Recovery Time
Corrupted messages are flagged by any node detecting an error. Such messages are aborted
and will be retransmitted automatically. The recovery time from detecting an error until the
start of the next message is at most 31 bit times, if there is no further error.
Fault Confinement
CAN nodes are able to distinguish short disturbances from permanent failures. Defective
nodes are switched off.
Connections
The CAN serial communication link is a bus to which a number of units may be connected.
This number has no theoretical limit. Practically the total number of units will be limited by
delay times and/or electrical loads on the bus line.
Single Channel
The bus consists of a single bidirectional channel that carries bits. From this data resynchro-
nization information can be derived. The way in which this channel is implemented is not
fixed in this specification. E.g. single wire (plus ground), two differential wires, optical fi-
bres, etc.
Bus values
The bus can have one of two complementary logical values: 'dominant' or 'recessive'. Du-
ring simultaneous transmission of 'dominant' and 'recessive' bits, the resulting bus value will
be 'dominant'. For example, in case of a wired-AND implementation of the bus, the
Ôdominant' level would be represented by a logical '0' and the 'recessive' level by a logical '1'.
Physical states (e.g. electrical voltage, light) that represent the logical levels are not given in
this specification.
Acknowledgement
All receivers check the consistency of the message being received and will acknowledge a
consistent message and flag an inconsistent message.
CAN Specification 2.0, Part B page 10
CAN in Automation, Am Weichselgarten 26, D-91058 Erlangen
Sleep Mode / Wake-up
To reduce the system's power consumption, a CAN-device may be set into sleep mode with-
out any internal activity and with disconnected bus drivers. The sleep mode is finished with
a wake-up by any bus activity or by internal conditions of the system. On wake-up, the
inter-nal activity is restarted, although the MAC sublayer will be waiting for the system's
oscilla-tor to stabilize and it will then wait until it has synchronized itself to the bus activity
(by checking for eleven consecutive 'recessive' bits), before the bus drivers are set to "on-
bus" again.
Oscillator Tolerance
The Bit Timing requirements allow ceramic resonators to be used in applications with trans-
mission rates of up to 125 kbit/s as a rule of thumb; for a more precise evaluation refer to
Dais, S; Chapman, M:
"Impact of Bit Representation on Transport Capacity and Clock
Accuracy in Serial Data Streams",
SAE Technical Paper Series 890532, Multiplexing in Automobil SP-773,
March 1989.
For the full bus speed range of the CAN protocol, a quartz oscillator is required.
CAN Specification 2.0, Part B page 11
CAN in Automation, Am Weichselgarten 26, D-91058 Erlangen
3 MESSAGE TRANSFER
3.1 Frame Formats
There are two different formats which differ in the length of the IDENTIFIER field: Frames
with the number of 11 bit IDENTIFIER are denoted Standard Frames . In contrast, frames
containing 29 bit IDENTIFIER are denoted Extended Frames.
3.2 Frame Types
Message transfer is manifested and controlled by four different frame types:
A DATA FRAME carries data from a transmitter to the receivers.
A REMOTE FRAME is transmitted by a bus unit to request the transmission of the DATA
FRAME with the same IDENTIFIER.
An ERROR FRAME is transmitted by any unit on detecting a bus error.
An OVERLOAD FRAME is used to provide for an extra delay between the preceding and
the succeeding DATA or REMOTE FRAMEs.
DATA FRAMEs and REMOTE FRAMEs can be used both in Standard Frame Format and
Extended Frame Format; they are separated from preceding frames by an INTERFRAME
SPACE.
3.2.1 DATA FRAME
A DATA FRAME is composed of seven different bit fields:
START OF FRAME, ARBITRATION FIELD, CONTROL FIELD, DATA FIELD,
CRC FIELD, ACK FIELD, END OF FRAME. The DATA FIELD can be of
length zero.
CAN Specification 2.0, Part B page 12
CAN in Automation, Am Weichselgarten 26, D-91058 Erlangen
START OF FRAME (Standard Format as well as Extended Format)
The START OF FRAME (SOF) marks the beginning of DATA FRAMES and REMOTE
FRAMEs. It consists of a single 'dominant' bit.
A station is only allowed to start transmission when the bus is idle (see 'INTERFRAME
Spacing'). All stations have to synchronize to the leading edge caused by START OF
FRAME (see 'HARD SYNCHRONIZATION') of the station starting transmission first.
ARBITRATION FIELD
The format of the ABITRATION FIELD is different for Standard Format and Extended
Format Frames.
- In Standard Format the ARBITRATION FIELD consists of the 11 bit IDENTIFIER and
the RTR-BIT. The IDENTIFIER bits are denoted ID-28 ... ID-18.
- In Extended Format the ARBITRATION FIELD consists of the 29 bit IDENTIFIER,
the
SRR-Bit, the IDE-Bit, and the RTR-BIT. The IDENTIFIER bits are denoted ID-28 ....
ID-0.
Interframe Interframe
Space DATA FRAME Space
or
Overload
Frame
Start of Frame
Arbitration Field
Control Field
Data Field
CRC Field
ACK Field
End of Frame
CAN Specification 2.0, Part B page 13
CAN in Automation, Am Weichselgarten 26, D-91058 Erlangen
In order to distinguish between Standard Format and Extended Format the reserved bit r1 in
previous CAN Specifications version 1.0-1.2 now is denoted as IDE Bit.
IDENTIFIER
IDENTIFIER - Standard Format
The IDENTIFIER's length is 11 bits and corresponds to the Base ID in Extended
For-mat. These bits are transmitted in the order from ID-28 to ID-18. The least
significant bit is ID-18. The 7 most significant bits (ID-28 - ID-22) must not be all
'recessive'.
IDENTIFIER - Extended Format
In contrast to the Standard Format the Extended Format consists of 29 bits. The
format comprises two sections:
Base ID with 11 bits and the
Extended ID with 18 bits
Standard Format
Arbitration Control Data
Field Field Field
S R I
O 11 bit IDENTIFIER T D r DLC
F R E 0
Extended Format
Arbitration Field Control Data
Field Field
S S I R
O 11 bit IDENTIFIER R D 18 bit IDENTIFIER T r r DLC
F R E R 1 0
CAN Specification 2.0, Part B page 14
CAN in Automation, Am Weichselgarten 26, D-91058 Erlangen
Base ID
The Base ID consists of 11 bits. It is transmitted in the order from ID-28 to ID-18. It is
equivalent to format of the Standard Identifier. The Base ID defines the Extended
Frame's base priority.
Extended ID
The Extended ID consists of 18 bits. It is transmitted in the order of ID-17 to ID-0.
In a Standard Frame the IDENTIFIER is followed by the RTR bit.
RTR BIT (Standard Format as well as Extended Format)
Remote Transmission Request BIT
In DATA FRAMEs the RTR BIT has to be 'dominant'. Within a REMOTE FRAME the
RTR BIT has to be 'recessive'.
In an Extended Frame the Base ID is transmitted first, followed by the IDE bit and the SRR
bit. The Extended ID is transmitted after the SRR bit.
SRR BIT (Extended Format)
Substitute Remote Request
The SRR bit is a recessive bits. It is transmitted in Extended Frames at the position of the
RTR Bit in Standard Frames and so substitutes the RTR-Bit in the Standard Frame.
Therefore, collisions of a Standard Frame and an Extended Frame, the Base ID (see 'Ex-
tended IDENTIFIER' below) of which is the same as the Standard Frame's Identifier, are
resolved in such a way that the Standard Frame prevails the Extended Frame.
IDE BIT (Extended Format)
Identifier Extension Bit
The IDE Bit belongs to
- the ARBITRATION FIELD for the Extended Format.
- the CONTROL FIELD for the Standard Format
本文档为【CAN Specification 2.0, Part B】,请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑,
图片更改请在作品中右键图片并更换,文字修改请直接点击文字进行修改,也可以新增和删除文档中的内容。
该文档来自用户分享,如有侵权行为请发邮件ishare@vip.sina.com联系网站客服,我们会及时删除。
[版权声明] 本站所有资料为用户分享产生,若发现您的权利被侵害,请联系客服邮件isharekefu@iask.cn,我们尽快处理。
本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用。
网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。