ISO 11898-1:2024
(Main)Road vehicles - Controller area network (CAN) - Part 1: Data link layer and physical coding sublayer
Road vehicles - Controller area network (CAN) - Part 1: Data link layer and physical coding sublayer
This document specifies the controller area network (CAN) data link layer (DLL) and the physical coding sub-layer (PCS). The CAN DLL features data fields of up to 2048 byte when the CAN extended data field length (XL) frame format is used. This document divides the CAN DLL into the logical link control (LLC) and the medium access control (MAC) sub-layers. The DLL’s service data unit (SDU), which interfaces the LLC and the MAC, is implemented by means of the LLC frame. The LLC frame also features the service data unit type (SDT) and the virtual CAN channel identifier (VCID), which provide higher-layer protocol configuration and identification information. How the higher-layer functions are handled is not specified in this document. There are five implementation options: 1) support of the CAN classic frame format only, not tolerating the CAN flexible data rate (FD) frame format; 2) support of the CAN classic frame format and tolerating the CAN FD frame format; 3) support of the CAN classic frame format and the CAN FD frame format; 4) support of the CAN classic frame format, the CAN FD frame format and the CAN XL frame format; 5) support of the CAN FD frame format for CAN FD light responders (Annex A). NOTE Nodes of the first option can communicate with nodes of the third and fourth option when only the CAN classic frame format is used. Nodes of the first option cannot communicate with nodes of the fifth option: any attempt at communication generates error frames. Therefore, new designs implementing the fourth option can communicate with all other nodes.
Véhicules routiers — Gestionnaire de réseau de communication (CAN) — Partie 1: Couche liaison de données et sous-couche de codage physique
General Information
Relations
Overview
ISO 11898-1:2024 - Road vehicles - Controller area network (CAN) - Part 1: Data link layer and physical coding sublayer defines the CAN data link layer (DLL) and physical coding sublayer (PCS) for in-vehicle and embedded network communications. The standard updates CAN to support larger payloads (up to 2048 bytes with the CAN XL frame format), divides the DLL into logical link control (LLC) and medium access control (MAC) sub-layers, and defines LLC frame elements such as the service data unit type (SDT) and virtual CAN channel identifier (VCID). Implementation options for backward and forward compatibility (classic CAN, CAN FD, CAN XL and CAN FD light responders) are also specified.
Key Topics and Requirements
- DLL architecture: Separation into LLC and MAC sub-layers, with an LLC frame acting as the DLL service data unit (SDU).
- Frame formats and lengths: Support for classic CAN, CAN FD and CAN XL (extended data length up to 2048 bytes).
- LLC features: SDT and VCID fields for higher-layer configuration and channel identification (higher-layer behavior not specified).
- MAC functions: Bus arbitration, inter-frame spacing, acknowledgement (ACK), error detection, error handling, retransmission and time stamping.
- PCS functions: Bit encoding/decoding, bit timing, synchronization, transmitter delay compensation, oscillator tolerance and optional PWM encoding.
- Fault management: Fault confinement, error-active/error-passive states and bus-off behavior; supervisor FCE (fault confinement entity) descriptions.
- Implementation options & compatibility:
- Five options: classic-only; classic with FD tolerance; classic+FD; classic+FD+XL; and FD-only light responders.
- Backwards compatibility notes: nodes supporting only classic CAN can interoperate with nodes supporting classic+FD/XL when only classic frames are used; classic-only nodes cannot communicate with FD-light-only responders.
- Services & interfaces: Definitions of PCS interface services (PCS_Data.Request/Indicate, PCS_Mode.Request, status indications).
Applications and Practical Use
- Automotive in-vehicle networks (powertrain, body electronics, ADAS communication)
- Commercial vehicles, off-highway machinery and industrial embedded systems requiring robust, real-time serial bus communication
- Electronic control unit (ECU) hardware and firmware design, CAN controller IP, transceiver manufacturers, and test tooling
- System integrators implementing mixed CAN ecosystems that need compatibility between classic CAN, CAN FD and CAN XL nodes
Who Should Use This Standard
- Automotive engineers designing CAN nodes, ECUs, gateways and transceivers
- Firmware and protocol stack developers implementing LLC/MAC/PCS layers
- Test and validation teams verifying timing, error handling and compatibility
- Semiconductor and IP vendors creating CAN controller cores and PHYs
Related Standards (high level)
- Other parts of ISO 11898 series (controller area network physical and higher-layer specifications)
- CAN FD and CAN XL technical specifications and relevant automotive communication profiles
Keywords: ISO 11898-1:2024, Controller Area Network, CAN data link layer, physical coding sublayer, CAN XL, CAN FD, LLC, MAC, VCID, automotive networking.
Frequently Asked Questions
ISO 11898-1:2024 is a standard published by the International Organization for Standardization (ISO). Its full title is "Road vehicles - Controller area network (CAN) - Part 1: Data link layer and physical coding sublayer". This standard covers: This document specifies the controller area network (CAN) data link layer (DLL) and the physical coding sub-layer (PCS). The CAN DLL features data fields of up to 2048 byte when the CAN extended data field length (XL) frame format is used. This document divides the CAN DLL into the logical link control (LLC) and the medium access control (MAC) sub-layers. The DLL’s service data unit (SDU), which interfaces the LLC and the MAC, is implemented by means of the LLC frame. The LLC frame also features the service data unit type (SDT) and the virtual CAN channel identifier (VCID), which provide higher-layer protocol configuration and identification information. How the higher-layer functions are handled is not specified in this document. There are five implementation options: 1) support of the CAN classic frame format only, not tolerating the CAN flexible data rate (FD) frame format; 2) support of the CAN classic frame format and tolerating the CAN FD frame format; 3) support of the CAN classic frame format and the CAN FD frame format; 4) support of the CAN classic frame format, the CAN FD frame format and the CAN XL frame format; 5) support of the CAN FD frame format for CAN FD light responders (Annex A). NOTE Nodes of the first option can communicate with nodes of the third and fourth option when only the CAN classic frame format is used. Nodes of the first option cannot communicate with nodes of the fifth option: any attempt at communication generates error frames. Therefore, new designs implementing the fourth option can communicate with all other nodes.
This document specifies the controller area network (CAN) data link layer (DLL) and the physical coding sub-layer (PCS). The CAN DLL features data fields of up to 2048 byte when the CAN extended data field length (XL) frame format is used. This document divides the CAN DLL into the logical link control (LLC) and the medium access control (MAC) sub-layers. The DLL’s service data unit (SDU), which interfaces the LLC and the MAC, is implemented by means of the LLC frame. The LLC frame also features the service data unit type (SDT) and the virtual CAN channel identifier (VCID), which provide higher-layer protocol configuration and identification information. How the higher-layer functions are handled is not specified in this document. There are five implementation options: 1) support of the CAN classic frame format only, not tolerating the CAN flexible data rate (FD) frame format; 2) support of the CAN classic frame format and tolerating the CAN FD frame format; 3) support of the CAN classic frame format and the CAN FD frame format; 4) support of the CAN classic frame format, the CAN FD frame format and the CAN XL frame format; 5) support of the CAN FD frame format for CAN FD light responders (Annex A). NOTE Nodes of the first option can communicate with nodes of the third and fourth option when only the CAN classic frame format is used. Nodes of the first option cannot communicate with nodes of the fifth option: any attempt at communication generates error frames. Therefore, new designs implementing the fourth option can communicate with all other nodes.
ISO 11898-1:2024 is classified under the following ICS (International Classification for Standards) categories: 43.040.15 - Car informatics. On board computer systems. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 11898-1:2024 has the following relationships with other standards: It is inter standard links to ISO 11898-1:2015. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO 11898-1:2024 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
International
Standard
ISO 11898-1
Third edition
Road vehicles — Controller area
2024-05
network (CAN) —
Part 1:
Data link layer and physical coding
sublayer
Véhicules routiers — Gestionnaire de réseau de
communication (CAN) —
Partie 1: Couche liaison de données et sous-couche de codage
physique
Reference number
© ISO 2024
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms. 6
5 Basic concepts of CAN . 8
5.1 CAN properties .8
5.2 Frame transmissions .9
5.3 Bus access method .11
5.4 Information routing .11
5.5 Network flexibility .11
5.6 Remote data request .11
5.7 Error detection .11
5.8 Error signalling and recovery time .11
5.9 Fault confinement . 12
5.10 Error-active . 12
5.11 Error-passive . . 12
5.12 Bus-off . 12
5.13 ACK . 12
5.14 Repetition of transmission attempts . 12
5.15 Network-wide data consistency . 12
5.16 Switchable operating modes of the PMA . 13
5.17 Bus states and MAC sub-layer phases . 13
6 CAN DLL specification . 14
6.1 General .14
6.2 Time stamping .14
6.3 DLL protocol .14
6.4 LLC sub-layer . 15
6.4.1 Overview . 15
6.4.2 Notifications .16
6.4.3 Structure of LLC frames . .16
6.4.4 Limited LLC frames .17
6.4.5 Services of LLC sub-layer .17
6.5 Functions of the LLC sub-layer .21
6.5.1 General .21
6.5.2 Flow control on re-arbitration .21
6.5.3 Flow control on retransmission .21
6.5.4 Frame acceptance filtering . 22
6.5.5 Overload notification . 22
6.5.6 Recovery management . 22
6.5.7 Time stamping . 22
6.6 MAC sub-layer . 23
6.6.1 Functions and rules . 23
6.6.2 Services of the MAC sub-layer . 23
6.6.3 Time reference points . 23
6.6.4 Functional model of MAC sub-layer architecture . 23
6.6.5 Specification of EF .27
6.6.6 Specification of OF . 28
6.6.7 Inter-frame space specification . 28
6.6.8 SOF . 30
6.6.9 Elements of the MAC frame. 30
6.6.10 MAC frame in CBFF and CEFF .31
iii
6.6.11 MAC frame in FBFF and FEFF . 33
6.6.12 MAC frame in XLFF.37
6.6.13 MAC frame coding .42
6.6.14 Data frame acknowledgement . .43
6.6.15 Frame validation .43
6.6.16 Order of bit transmission . .43
6.6.17 Medium access method .43
6.6.18 MAC data consistency .45
6.6.19 Restricted operation .45
6.6.20 Bus monitoring .45
6.6.21 Error handling and overload handling .45
7 PL specifications .49
7.1 General and functional modelling . 49
7.2 Services of the PCS interface . 50
7.2.1 Requirements . 50
7.2.2 PCS_Data.Request . 50
7.2.3 PCS_Data.Indicate . 50
7.2.4 PCS_Mode.Request. 50
7.2.5 PCS_Status.Transmitter .51
7.2.6 PCS_Status.Receiver .51
7.3 PCS .51
7.3.1 Bit encoding/decoding .51
7.3.2 Bit time .51
7.3.3 Configuration of the bit time parameters . 55
7.3.4 Transmitter delay compensation . 56
7.3.5 Synchronization . 58
7.3.6 Tolerance range of the oscillator frequencies . 60
7.4 Attachment unit interface .61
7.4.1 General .61
7.4.2 PCS to PMA symbols .61
7.4.3 PMA to PCS symbol .62
7.5 PWM encoding .62
7.5.1 General function and definitions .62
7.5.2 PCS without PWM encoding . 63
7.5.3 PCS sub-layer with PWM encoding . 63
8 Description of supervisor FCE .66
8.1 Fault confinement . 66
8.1.1 Objectives . 66
8.1.2 Strategies . 66
8.1.3 Fault confinement interface specification . 66
8.1.4 Rules of fault confinement . 69
8.1.5 Node start-up .71
8.2 Bus failure management .71
Annex A (normative) CAN FD light — Data link layer and physical coding sub-layer requirements
of responder nodes .72
Annex B (informative) Configuration interface .80
Annex C (informative) Additional information .81
Bibliography .82
iv
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO document should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31, Data
communication.
This third edition cancels and replaces the second edition (ISO 11898-1:2015), which has been technically
revised.
The main changes are as follows:
— CAN XL requirements added;
— CAN FD light protocol (Annex A) requirements added;
— editorial corrections.
A list of all parts in the ISO 11898 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
v
Introduction
The ISO 11898 series provides requirement specifications for the controller area network (CAN) data
link layer and physical layer. It is intended for chip implementers, e.g. this document can be used for CAN
protocol controllers and ISO 11898-2 for CAN transceivers. The CAN data link layer models the open systems
interconnection (OSI) data link layer; it is internally subdivided into logic link control (LLC) and medium
access control (MAC). This document also specifies the physical coding sub-layer (PCS) by means of the
attachment unit interface (AUI). The PCS also provides the pulse-with modulation (PWM) encoding to be
linked to a CAN SIC XL transceiver, which provides the PWM decoding.
The OSI layers above the data link layer (e.g. the network layer) are not specified in the ISO 11898 series of
specifications.
Figure 1 shows the relationship between the OSI layers and the CAN sub-layers.
Key
AUI attachment unit interface
LLC logic link control
MAC medium access control
MDI medium dependent interface
PCS physical coding sub-layer
PMA physical medium attachment
PMD physical medium dependent
PWM pulse-width modulation
Figure 1 — CAN data link and physical sub-layers in relation to the OSI model
vi
International Standard ISO 11898-1:2024(en)
Road vehicles — Controller area network (CAN) —
Part 1:
Data link layer and physical coding sublayer
1 Scope
This document specifies the controller area network (CAN) data link layer (DLL) and the physical coding
sub-layer (PCS). The CAN DLL features data fields of up to 2048 byte when the CAN extended data field
length (XL) frame format is used.
This document divides the CAN DLL into the logical link control (LLC) and the medium access control (MAC)
sub-layers. The DLL’s service data unit (SDU), which interfaces the LLC and the MAC, is implemented by
means of the LLC frame. The LLC frame also features the service data unit type (SDT) and the virtual CAN
channel identifier (VCID), which provide higher-layer protocol configuration and identification information.
How the higher-layer functions are handled is not specified in this document. There are five implementation
options:
1 support of the CAN classic frame format only, not tolerating the CAN flexible data rate (FD) frame format;
2 support of the CAN classic frame format and tolerating the CAN FD frame format;
3 support of the CAN classic frame format and the CAN FD frame format;
4 support of the CAN classic frame format, the CAN FD frame format and the CAN XL frame format;
5 support of the CAN FD frame format for CAN FD light responders (Annex A).
NOTE Nodes of the first option can communicate with nodes of the third and fourth option when only the CAN
classic frame format is used. Nodes of the first option cannot communicate with nodes of the fifth option: any attempt
at communication generates error frames. Therefore, new designs implementing the fourth option can communicate
with all other nodes.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
arbitration mode
operating mode of the physical coding sub-layer (PCS) in which it is allowed that dominant bits can overwrite
recessive bits
3.2
arbitration phase
phase in which the nominal bit time (3.42) is used
3.3
attachment unit interface
AUI
interface between the physical coding sub-layer (PCS) and the physical medium attachment (PMA) sub-layer
3.4
bit stuffing
frame coding method providing bus state (3.8) changes required for periodic resynchronization when using
a non-return-to-zero (NRZ) (3.43) bit representation
Note 1 to entry: Two types of bit stuffing exist: dynamic bit stuffing and fixed bit stuffing. The transmitter (3.54) adds
stuff bits into the outgoing bit stream and receivers (3.48) de-stuff the data frames (3.16) and the remote frames (3.49)
i.e. the inverse procedure is carried out.
3.5
bus
shared medium of any topology
3.6
bus comparator
physical coding attachment comparator
electronic circuit converting analogue signals used for transfer across the communication medium back into
digital signals
3.7
bus driver
electronic circuit converting digital signals into analogue signals so that these signals can be transferred
across the communication medium, i.e. the bus (3.5)
3.8
bus state
one of two complementary logical states: dominant or recessive
Note 1 to entry: The dominant state represents the logical 0, and the recessive state represents the logical 1. This
document uses the terms "dominant" and "recessive" for the bit values of the medium access control (MAC) frame,
independent of the transceiver mode (3.53). When no transmission is in progress, the bus (3.5) is idle (3.33). During
idle time, it is in recessive state.
3.9
bus-off
state of a node (3.39) in which it does not influence the bus (3.5)
3.10
classic base frame format
CBFF
format for data frames (3.16) or remote frames (3.49) using an 11-bit identifier (3.31) and which are
transmitted with one single bit rate and up to and including eight data bytes
3.11
classic extended frame format
CEFF
format for data frames (3.16) or remote frames (3.49) using a 29-bit identifier (3.31) and which are
transmitted with one single bit rate and up to and including eight data bytes
3.12
classic frame
data frame (3.16) or remote frame (3.49) using the CC base frame format (3.10) or the classic extended frame
format (3.11)
3.13
commander node
node (3.39) that sends data frames to responder nodes (3.50) to initiate a controller area network (CAN) FD
light (3.26) communication
3.14
data bit rate
number of bits per time during data phase (3.17), independent of bit encoding/decoding
3.15
data bit time
duration of one bit in data phase (3.17), defined by a number of data time quanta in the bit
3.16
data frame
DF
frame (3.28) containing application content
3.17
data phase
phase in which the data bit time (3.15) is used
3.18
data RX mode
operating mode of the physical medium attachment (PMA) sub-layer in which the bus states (3.8) can be
different from the bus states in the arbitration mode (3.1)
3.19
data TX mode
operating mode of the physical medium attachment (PMA) sub-layer in which it can drive the bus states (3.8)
differently than it drives them in the arbitration mode (3.1)
3.20
edge
difference in bus states (3.8) between two consecutive time quanta
3.21
error frame
EF
frame (3.28) indicating the detection of an error condition
3.22
FD base frame format
FBFF
format for data frames (3.16) using an 11-bit identifier (3.31), which can be transmitted with a flexible bit rate
3.23
FD enabled
able to receive and to transmit FD frames (3.25) as well as CC frames (3.12)
3.24
FD extended frame format
FEFF
format for data frames (3.16) using a 29-bit identifier (3.31), which can be transmitted with a flexible bit rate
3.25
FD frame
data frame (3.16) using the FD base frame format (3.22) or FD extended frame format (3.24)
3.26
FD light
implementation option for a responder node (3.50) that is based on a subset of the controller area network
(CAN) functionality.
3.27
FD tolerant
not able to receive or to transmit FD frames (3.25), but not disturbing them
3.28
frame
protocol data unit of the data link layer specifying the arrangement and meaning of bits or bit fields in the
sequence of transfer across the transmission medium
3.29
handle
label of one or multiple logical link control (LLC) frames, or data link layer service data units (LSDU), the
data link layer (DLL)'s interface data coming from the higher open systems interconnection (OSI) layers
(network layer or transport layer)
3.30
higher-layer protocol
HLP
protocol (3.46) above the data link layer protocol, e.g. transport layer protocol or network layer protocol
according to the open system interconnection model
3.31
identifier
ID
unique label reflecting the priority (3.45) of a particular frame (3.28)
3.32
identifier-based arbitration
carrier sense multiple access/collision resolution arbitration procedure resolving bus (3.5) contention when
multiple nodes (3.39) simultaneously access the bus
3.33
idle
operating condition of the bus (3.5) after the completion of a frame (3.28) until the next frame starts
3.34
idle condition
detection of a consecutive sequence of 11 sampled recessive bits
3.35
integrating
status of a node (3.39) waiting on an idle condition (3.34) after starting the protocol operation during bus-off
(3.9) recovery or after a protocol exception event (3.47)
3.36
minimum time quantum
smallest time quantum that can be configured for the specific node (3.39)
3.37
multi master
network with several nodes where every node (3.39) is allowed to start sending a frame (3.28) when the
controller area network (CAN) bus (3.5) is idle (3.33)
3.38
multicast
address method transmitting a single frame (3.28) to a group of nodes (3.39)
Note 1 to entry: A broadcast is a special case of multicast, whereby a single frame is addressed to all nodes
simultaneously.
3.39
node
assembly, linked to a communication network, capable of communicating across the network according to
a communication protocol specification (a node can be in one of four states: integrating (3.35), idle (3.33),
receiver (3.48), or transmitter (3.54))
Note 1 to entry: A node operating in a controller area network (CAN) is called a CAN node.
3.40
node clock
time base to coordinate the bit-time-related state machines in controller area network (CAN) nodes (3.39)
3.41
nominal bit rate
number of bits per time during an arbitration phase (3.2), independent of the bit-encoding/decoding
3.42
nominal bit time
duration of one bit in an arbitration phase (3.2), defined by a number of nominal time quanta in the bit
3.43
non-return-to-zero
NRZ
method of representing binary signals, i.e. within one and the same bit time, the signal level does not change,
where a stream of bits having the same logical value provides no edges (3.20)
3.44
overload frame
OF
frame (3.28) indicating an overload condition
3.45
priority
attribute to a data frame (3.16) and to a remote frame (3.49) controlling its ranking during the arbitration
Note 1 to entry: A high priority increases the probability that a data frame or a remote frame wins the arbitration
process. Further details are given in 6.6.17.5.
3.46
protocol
formal set of conventions or rules for the exchange of information between nodes (3.39), including the
specification of frame administration, frame transfer and physical medium attachment (PMA)
3.47
protocol exception event
either exception from the formal set of conventions or rules to be able to tolerate future new frame formats,
or reaction to errors when controller area network (CAN) XL is used with error signalling disabled
3.48
receiver
node (3.39) that, while the bus (3.5) is not idle (3.33), is neither transmitting nor integrating (3.35)
3.49
remote frame
RF
frame (3.28) that requests the transmission of a dedicated data frame (3.16)
3.50
responder node
node (3.39) that is controlled by a commander node (3.13) using controller area network (CAN) FD light
(3.26) communication
3.51
stuff bit count
SBC
number of stuff bits in a frame (3.28) before the cyclic redundancy check (CRC) field, not including fixed
stuff bits
3.52
transceiver
electronic circuit, implementing the physical medium attachment (PMA) sub-layer, that connects controller
area network (CAN) nodes (3.39) to a CAN bus (3.5) consisting of a bus comparator (3.6) and a bus driver (3.7)
3.53
transceiver mode
operating mode of the physical medium attachment (PMA) sub-layer
3.54
transmitter
node (3.39) sending a data frame (3.16) or a remote frame (3.49)
Note 1 to entry: A node remains a transmitter until the bus (3.5) is idle (3.33) again or until the node loses arbitration.
3.55
XL frame
data frame (3.16) using the XL frame format (3.56)
3.56
XL frame format
XLFF
format for data frames (3.16) using an 11-bit identifier (3.31), including up to 2048 data bytes, where the bit
rate is switched at the beginning and at the end of the data phase (3.17)
4 Symbols and abbreviated terms
For the purposes of this document, the following symbols and abbreviated terms apply.
ACK acknowledgement
ADH arbitration to data high
ADS arbitration to data sequence
AF acceptance field
AH1 arbitration high 1
AH2 arbitration high 2
AL1 arbitration low 1
BCH code Bose-Chaudhuri-Hocquenghem code
BRS bit rate switch
CAN controller area network
CC classic
CRC cyclic redundancy check
DAH data arbitration high
DAS data to arbitration sequence
DF data frame
DH data high bit
DL data low bit
DLC data length code
DLL data link layer
EOF end of frame
ESI error state indicator
FCE fault confinement entity
FCP format check pattern
FCRC frame CRC
FD flexible data rate
FDF flexible data rate format indicator
FTYP frame type
IDE identifier extension
IPT information processing time
LLC logical link control
LME layer management entity
LPDU logical link control protocol data unit
LSB least significant bit
LSDU logical link control service data unit
MAC medium access control
MPDU medium access control protocol data unit
MSB most significant bit
nCRC order of the generated polynomia
NRZ non-return-to-zero
OF overload frame
OSI open systems interconnection
PCRC preface cyclic redundancy check
PCS physical coding sub-layer
PDU protocol data unit
PL physical layer
PMA physical medium attachment
PMD physical medium dependent
PWM pulse width modulation
PWML pulse width modulation long phase
PWMO pulse width modulation offset time
PWMS pulse width modulation short phase
resXL reserved bit extended data field length format
RRS remote request substitution
RTR remote transmission request
SDT service data unit type
SDU service data unit
SEC simple/extended content
SIC signal improvement capability
SJW synchronization jump width
SOF start of frame
SSP secondary sample point
t time quantum/time quanta
q
t minimum time quantum
q.min
VCID virtual controller area network channel identifier
XL extended data field length
XLF extended data field length format indicator
5 Basic concepts of CAN
5.1 CAN properties
A CAN has the following properties:
— multi-master priority-based bus access;
— non-destructive content-based arbitration;
— all frame transfers are done as broadcast;
— multicast frame transfer by acceptance filtering;
— remote data request;
— configuration flexibility;
— error detection and error signalling;
— distinction between temporary errors and permanent failures of nodes and autonomous switching-off of
defective nodes;
— retransmission of frames that lose bus arbitration, are not acknowledged, or are invalided by errors;
— network-wide data consistency.
The following properties can be omitted by configuration: retransmission, error signalling, network-wide
data consistency and remote data request.
A subset of the CAN FD data link layer may be implemented as a CAN FD light responder node. Annex A shall
be followed when a CAN FD light responder node is implementing a subset of the CAN FD data link layer.
Configuration options for CAN implementations are described in Annex B.
The differences between implementation options are described in Annex C.
5.2 Frame transmissions
The DLL sends different frames: data frames (DF), remote frames (RF), error frames (EF) and overload
frames (OF). When the bus is idle, a CAN node may start the transmission of a DF or an RF. The bus is idle
when no frame is transmitted. A node starts to send an EF or an OF when an error condition or an overload
condition, respectively, is detected by the node.
Figure 2 shows the DFs and RFs specified in this document. This figure is also provided in electronic form at:
https:// standards .iso .org/ iso/ 11898/ -1/ ed -3/ en.
Figure 2 — CAN frame formats
NOTE Whether the FDF bit in FBFF and FEFF take part in arbitration or not, is specified in 6.6.11.
5.3 Bus access method
If two or more nodes start to transmit DFs or RFs at the same time, the bus access conflict is resolved by
arbitration using the identifier. The mechanism of arbitration ensures that neither information nor time is
lost. The transmitter with the DF or RF of the highest priority gains the bus access. A DF with the same ID as
an RF wins bus arbitration.
5.4 Information routing
Receivers accept or do not accept information based upon a process called frame acceptance filtering, which
decides whether the received information is relevant or not. There is no need for receivers to know the
transmitter of the information and vice versa.
5.5 Network flexibility
Nodes can be added to the network without requiring any change in the software or hardware of any node,
if the added node is not the transmitter of any DF and if the added node does not require any additional
transmitted data.
5.6 Remote data request
By sending an RF, a node requiring data requests another node to send the corresponding DF: the RF and the
corresponding DF are named by the same identifier and using the same DLC.
NOTE 1 The node providing the remotely requested DF (same ID) decides whether the updated data is mapped into
the DF or the data in the transmit buffer is sent.
NOTE 2 The node providing the remotely requested DF (same ID) decides how to respond to an RF with
mismatching DLC.
5.7 Error detection
For detecting errors, the following measures are provided:
— monitoring (transmitters compare the transmitted bit levels with the bit levels detected on the network);
— 15-bit CRC for CC frames, 17-bit CRC for FD frames with up to 16 data-field bytes, 21-bit CRC for FD
Frames with 20 to 64 data-field bytes,13-bit PCRC and 32-bit frame CRC for XL frames;
— stuff bit count check for FD frames and XL frames;
— dynamic bit stuffing with a stuff width of five (except in the CRC field of FD frames and after the arbitration
field of XL frames);
— fixed bit stuffing with a stuff rate of 5 (used in the FD CRC field);
— fixed bit stuffing with a stuff rate of 11 (used in the XL data phase);
— frame format check;
— ACK check.
5.8 Error signalling and recovery time
Corrupted frames are flagged by transmitting nodes and by error-active receiving nodes. Such frames are
aborted and retransmitted according to the implemented recovery procedure (see 6.6.21). The recovery
time from detecting an error until the possible start of the next frame is 17 to 23 nominal bit times (in the
case of nodes in error passive mode up to 31 nominal bit times) if there are no further errors.
For CAN XL nodes, error signalling depends on the node configuration. It can be enabled or disabled as
specified in 6.6.21.1. If error signalling is disabled, the node does not send EFs or OFs. The node reacts on
error conditions and overload conditions as specified in 6.6.21.4.
NOTE Nodes with disabled error signalling are not interoperable with CAN nodes with enabled error signalling.
5.9 Fault confinement
CAN nodes can distinguish short disturbances from permanent failures. Defective transmitting nodes are
switched off. Switched off means a node is logically disconnected from the bus, so tha
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...