ISO 11898-1:2003
(Main)Road vehicles - Controller area network (CAN) - Part 1: Data link layer and physical signalling
Road vehicles - Controller area network (CAN) - Part 1: Data link layer and physical signalling
ISO 11898-1:2003 specifies the data link layer (DLL) and physical signalling of the controller area network (CAN): a serial communication protocol that supports distributed real-time control and multiplexing for use within road vehicles. While describing the general architecture of CAN in terms of hierarchical layers according to the ISO reference model for open systems interconnection (OSI) established in ISO/IEC 7498-1, it provides the characteristics for setting up an interchange of digital information between modules implementing the CAN DLL -- itself specified according to ISO/IEC 8802-2 and ISO/IEC 8802-3 -- with detailed specification of the logical link control (LLC) sublayer and medium access control (MAC) sublayer.
Véhicules routiers — Gestionnaire de réseau de communication (CAN) — Partie 1: Couche liaison de données et signalisation physique
L'ISO 11898-1:2003 spécifie la couche liaison de données (DLL) et la signalisation physique du gestionnaire de réseau de communication (CAN): un protocole de communication série qui prend en charge la commande répartie en temps réel et le multiplexage, pour les besoins des véhicules routiers. Elle décrit l'architecture générale du CAN, en termes de couches hiérarchiques, conformément au modèle de référence ISO pour l'interconnexion de systèmes ouverts (OSI) spécifié dans l'ISO/CEI 7498-1, et fournit les caractéristiques de configuration d'un échange d'informations numériques entre modules par mise en oeuvre de la DLL du CAN -- celle-ci étant spécifiée conformément à l'ISO/CEI 8802-2 et à l'ISO/CEI 8802-3 -- avec des spécifications détaillées de la sous-couche de contrôle de liaison logique (LLC) et de la sous-couche de contrôle d'accès au support (MAC).
General Information
Relations
Frequently Asked Questions
ISO 11898-1:2003 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 signalling". This standard covers: ISO 11898-1:2003 specifies the data link layer (DLL) and physical signalling of the controller area network (CAN): a serial communication protocol that supports distributed real-time control and multiplexing for use within road vehicles. While describing the general architecture of CAN in terms of hierarchical layers according to the ISO reference model for open systems interconnection (OSI) established in ISO/IEC 7498-1, it provides the characteristics for setting up an interchange of digital information between modules implementing the CAN DLL -- itself specified according to ISO/IEC 8802-2 and ISO/IEC 8802-3 -- with detailed specification of the logical link control (LLC) sublayer and medium access control (MAC) sublayer.
ISO 11898-1:2003 specifies the data link layer (DLL) and physical signalling of the controller area network (CAN): a serial communication protocol that supports distributed real-time control and multiplexing for use within road vehicles. While describing the general architecture of CAN in terms of hierarchical layers according to the ISO reference model for open systems interconnection (OSI) established in ISO/IEC 7498-1, it provides the characteristics for setting up an interchange of digital information between modules implementing the CAN DLL -- itself specified according to ISO/IEC 8802-2 and ISO/IEC 8802-3 -- with detailed specification of the logical link control (LLC) sublayer and medium access control (MAC) sublayer.
ISO 11898-1:2003 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:2003 has the following relationships with other standards: It is inter standard links to ISO 11898-1:2015, ISO 11898:1993/Amd 1:1995, ISO 11898:1993. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO 11898-1:2003 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 ISO
STANDARD 11898-1
First edition
2003-12-01
Road vehicles — Controller area network
(CAN) —
Part 1:
Data link layer and physical signalling
Véhicules routiers — Gestionnaire de réseau de communication
(CAN) —
Partie 1: Couche liaison et signalisation physique
Reference number
©
ISO 2003
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO 2003
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2003 — All rights reserved
Contents Page
Foreword. v
1 Scope. 1
2 Conformance. 1
3 Normative references. 1
4 Terms and definitions. 2
5 Symbols and abbreviated terms. 3
6 Basic concepts of CAN. 5
6.1 CAN properties. 5
6.2 Frames. 5
6.3 Bus access method . 5
6.4 Information routing. 5
6.5 System flexibility. 5
6.6 Data consistency. 5
6.7 Remote data request. 6
6.8 Error detection. 6
6.9 Error signalling and recovery time. 6
6.10 ACK. 6
6.11 Automatic retransmission. 6
6.12 Fault confinement. 6
6.13 Error-active. 6
6.14 Error-passive. 6
6.15 Bus-off. 7
7 Layered architecture of CAN. 7
7.1 Reference to OSI model. 7
7.2 Protocol specification. 8
7.3 Format description of services. 9
7.4 LLC interface. 9
8 Description of LLC sublayer . 10
8.1 General. 10
8.2 Services of LLC sublayer . 10
8.3 Functions of LLC sublayer . 14
8.4 Structure of LLC frames. 14
8.5 Limited LLC frames. 16
9 Interface between LLC and MAC . 16
9.1 Services. 16
9.2 TTC option . 16
10 Description of MAC sublayer. 17
10.1 General. 17
10.2 Services of MAC sublayer. 17
10.3 Functional model of MAC sublayer architecture. 21
10.4 Structure of MAC frames. 24
10.5 Frame coding . 29
10.6 Order of bit transmission. 30
10.7 Frame validation .30
10.8 Medium access method. 30
10.9 Error detection . 32
10.10 Error signalling . 33
10.11 Overload signalling .33
10.12 Bus monitoring.33
11 LLC and MAC sublayer conformance .33
12 Physical layer.33
12.1 General.33
12.2 Functional model .33
12.3 Services of PL.34
12.4 PLS sublayer specification .35
12.5 PLS-PMA interface specification .39
13 Description of supervisor.39
13.1 Fault confinement.39
13.2 Bus failure management.44
Bibliography.45
iv © ISO 2003 — All rights reserved
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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 11898-1 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,
Electrical and electronic equipment.
This first edition of ISO 11898-1, together with ISO 11898-2, replaces ISO 11898:1993, which has been
technically revised. Whereas the replaced International Standard covered both the CAN DLL and the high-
speed PL, ISO 11898-1 specifies the DLL, including LLC and MAC sublayers, as well as the PLS sublayer,
while ISO 11898-2 specifies the high-speed MAU.
ISO 11898 consists of the following parts, under the general title Road vehicles — Controller area network
(CAN):
Part 1: Data link layer and physical signalling
Part 2: High-speed medium access unit
Part 3: Low-speed, fault-tolerant, medium dependent interface
Part 4: Time-triggered communication
INTERNATIONAL STANDARD ISO 11898-1:2003(E)
Road vehicles — Controller area network (CAN) —
Part 1:
Data link layer and physical signalling
1 Scope
This part of ISO 11898 specifies the data link layer (DLL) and physical signalling of the controller area network
(CAN): a serial communication protocol that supports distributed real-time control and multiplexing for use
within road vehicles. While describing the general architecture of CAN in terms of hierarchical layers
according to the ISO reference model for open systems interconnection (OSI) established in ISO/IEC 7498-1,
it provides the characteristics for setting up an interchange of digital information between modules
implementing the CAN DLL — itself specified according to ISO/IEC 8802-2 and ISO/IEC 8802-3 — with
detailed specification of the logical link control (LLC) sublayer and medium access control (MAC) sublayer.
2 Conformance
The conformance of the DLL shall be tested according to ISO 16845.
3 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The
Basic Model
ISO/IEC 8802-2, Information technology — Telecommunications and information exchange between
systems — Local and metropolitan area networks — Specific requirements — Part 2: Logical link control
ISO/IEC 8802-3, Information technology — Telecommunications and information exchange between
systems — Local and metropolitan area networks — Specific requirements — Part 3: Carrier sense multiple
access with collision detection (CSMA/CD) access method and physical layer specifications
ISO 16845, Road vehicles — Controller area network (CAN) — Conformance test plan
4 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
4.1
bit rate
number of bits per time during transmission, independent of bit representation
4.2
bit stuffing
filling using bits to provide bus state changes required for periodic resynchronization when using an NRZ bit
representation
NOTE Whenever the transmitting logic encounters a certain number (stuff width) of consecutive bits of equal value in
the data, it automatically stuffs a bit of complementary value — a stuff bit — into the outgoing bit stream. Receivers destuff
the frame, i.e. the inverse procedure is carried out.
4.3
bit time
t
B
duration of one bit
4.4
bus
topology of a communication network, where all nodes are reached by passive links which allow transmission
in both directions
4.5
bus comparator
device converting physical signals used for transfer across the communication medium back into logical
information or data signals
4.6
bus driver
device converting information or data signals into physical signals so that these signals can be transferred
across the communication medium
4.7
bus state
one of two complementary logical states: dominant or recessive
NOTE The dominant state represents the logical 0, and the recessive state represents the logical 1. During
simultaneous transmission of dominant and recessive bits, the resulting bus state is dominant. When no transmission is in
progress, the bus is idle. During that time it is in the recessive state.
4.8
contention-based arbitration
CSMA arbitration procedure where simultaneous access of multiple nodes results in a contention
4.9
frame
data link PDU specifying the arrangement and meaning of bits or bit fields in the sequence of transfer across
the transmission medium
4.10
multicast
addressing where a single frame is addressed to a group of nodes simultaneously
NOTE Broadcast is a special case of multicast, whereby a single frame is addressed to all nodes simultaneously.
2 © ISO 2003 — All rights reserved
4.11
multimaster
system partitioned into several nodes where every node may temporarily control the action of other nodes
4.12
node
assembly, linked to a communication network, capable of communicating across the network according to a
communication protocol specification
NOTE A CAN node is a node communicating across a CAN network.
4.13
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
4.14
priority
attribute to a frame controlling its ranking during arbitration, a high priority increases the probability that a
frame wins the arbitration process
4.15
protocol
formal set of conventions or rules for the exchange of information between nodes, including the specification
of frame administration, frame transfer and PL
4.16
receiver
node when if it is not a transmitter and the bus is not idle
4.17
time-triggered communication
option where a frame can be transmitted at a specific time slot, also providing a global synchronization of
clocks and allowing the disabling of the automatic retransmission of frames
4.18
transmitter
node originating a data frame or remote frame, which stays transmitter until the bus is idle again or until the
node loses arbitration
5 Symbols and abbreviated terms
ACK acknowledgement
BCH Bose-Chaudhuri-Hocquenghem
BR bit rate
t bit time
B
CAN controller area network
CRC cyclic redundancy check
CSMA carrier sense multiple access
DLC data length code
DLL data link layer
EOF end of frame
FCE fault confinement entity
IC integrated circuit
IDE identifier extension flag
LAN local area network
LLC logical link control
LME layer management entity
LPDU LLC protocol data unit
LSB least significant bit
LSDU LLC service data unit
MA medium access
MAC medium access control
MAU medium access unit
MDI medium dependent interface
MPDU MAC protocol data unit
MSB most significant bit
MSDU MAC service data unit
NRZ non-return-to-zero
OSI open system interconnection
OVLD overload
PCI protocol control information
PDU protocol data unit
PL physical layer
PLS physical signalling
PMA physical medium attachment
REC receive error counter
RTR remote transmission request
SDU service data unit
SJW synchronization jump width
SOF start of frame
SRR substitute remote request
TEC transmit error counter
TTC time triggered communication
4 © ISO 2003 — All rights reserved
6 Basic concepts of CAN
6.1 CAN properties
CAN shall have the following properties:
multi-master priority-based bus access;
non-destructive contention-based arbitration;
multicast frame transfer by acceptance filtering;
remote data request;
configuration flexibility;
system-wide data consistency;
error detection and error signalling;
automatic retransmission of frames that have lost arbitration or have been destroyed by errors during
transmission;
distinction between temporary errors and permanent failures of nodes and autonomous switching-off of
defective nodes.
6.2 Frames
Information on the bus shall be sent in fixed format frames of different but limited length. When the bus is idle,
any connected node may start to transmit a new frame.
6.3 Bus access method
When the bus is idle, any node may start to transmit a frame. If two or more nodes start to transmit frames at
the same time, the bus access conflict shall be resolved by contention-based arbitration using the identifier.
The mechanism of arbitration shall ensure that neither information nor time is lost. The transmitter with the
frame of highest priority shall gain the bus access.
6.4 Information routing
In CAN systems a node shall not make use of any information about the system configuration (e.g. node
address). Instead, 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.
6.5 System flexibility
Nodes may be added to the CAN network without requiring any change in the software or hardware of any
node, if the added node is not the transmitter of any data frame and if the added node does not require any
additional transmitted data.
6.6 Data consistency
Within CAN a frame shall simultaneously be accepted either by all nodes or by none. Thus data consistency
shall be a property of the system achieved by the concepts of multicast and by error handling.
6.7 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 shall be named by the same identifier.
6.8 Error detection
For detecting errors, the following measures shall be provided:
monitoring (transmitters compare the bit levels to be transmitted with the bit levels detected on the bus);
15-bit CRC;
variable bit stuffing with a stuff width of 5;
frame check;
acknowledge check.
6.9 Error signalling and recovery time
Corrupted frames shall be flagged by any transmitting node and any normally operating (error-active)
receiving node. Such frames shall be aborted and retransmitted according to the implemented recovery
procedure (see 8.3.4). The recovery time from detecting an error until the possible start of the next frame shall
be typically seventeen (17) to twenty-three (23) bit times [in the case of a heavily disturbed bus, up to thirty-
one (31) bit times], if there are no further errors.
6.10 ACK
All receivers shall check the consistency of the received frame and shall acknowledge a consistent frame and
shall flag an inconsistent frame. A frame that is not acknowledged is corrupted and shall be flagged by the
transmitting node.
6.11 Automatic retransmission
Frames that have lost arbitration and frames that have been disturbed by errors during transmission shall be
retransmitted automatically when the bus is idle again. A frame that will be retransmitted shall be handled as
any other frame, i.e. it participates in the arbitration process to gain bus access. In case of TTC, the automatic
retransmission shall be disabled (see 9.2.5).
6.12 Fault confinement
CAN nodes shall be able to distinguish short disturbances from permanent failures. Defective transmitting
nodes shall be switched off. Switched off means a node is logically disconnected from the bus, so that it can
neither send nor receive any frames (see 13.1.4.3).
6.13 Error-active
An error-active node shall normally take part in bus communication and send an active error flag when an
error has been detected. The active error flag shall consist of six (6) consecutive dominant bits and shall
violate the rule of bit stuffing and all fixed formats appearing in a regular frame (see 13.1.4.2).
6.14 Error-passive
An error-passive node shall not send an active error flag. It takes part in bus communication, but when an
error has been detected a passive error flag shall be sent. The passive error flag shall consist of six (6)
6 © ISO 2003 — All rights reserved
consecutive recessive bits. After transmission, an error-passive node shall wait some additional time before
initiating a further transmission (see suspend transmission in 10.4.6.4, and 13.1.4.2).
6.15 Bus-off
A node shall be in the bus-off state when it is switched off from the bus due to a request of FCE. In the bus-off
state, a node shall neither send nor receive any frames. A node shall start the recovery from bus-off state only
upon a user request.
7 Layered architecture of CAN
7.1 Reference to OSI model
According to the OSI reference model, the CAN architecture of this part of ISO 11898 shall represent the two
layers,
DLL, and
PL.
See Figure 1.
Figure 1 — Layered architecture of CAN
According to ISO/IEC 8802-2 and ISO/IEC 8802-3, the DLL has been subdivided into
LLC, and
MAC.
The PL has been subdivided into
PLS,
PMA, and
MDI.
The MAC sublayer operations shall be supervised by an FCE. Fault confinement shall be a self-checking
mechanism that distinguishes short disturbances from permanent failures (for fault confinement, see 13.1).
The PL may be supervised by an entity that detects and manages failures of the physical medium.
7.2 Protocol specification
Two peer protocol entities shall communicate with each other by exchanging frames or PDUs.
An NPDU shall consist of N-PCI and (N)-user data. NPDU shall be passed to a (N − 1)-layer entity via a
(N − 1)-SAP. The NPDU shall be passed by means of the (N − 1)-SDU to the (N − 1)-layer, the services of
which allow the transfer of the NPDU. The SDU shall be the interface data whose identity is preserved
between (N)-layer entities, i.e. it represents the logical data unit transferred by a service. The DLL of the CAN
protocol shall not provide either the means for mapping one SDU into multiple PDUs or for mapping multiple
SDUs into one PDU, i.e. an NPDU is directly constructed from the associated NSDU and the layer-specific
control information N-PCI. Figure 2 illustrates the data link sublayer interactions.
Figure 2 — Protocol layer interactions
8 © ISO 2003 — All rights reserved
7.3 Format description of services
7.3.1 Format description of service primitives
Service primitives shall be written as
service.type (
[parameter1,.]
)
where service indicates the name of the service, e.g. L_Data for data transfer service provided by the LLC
sublayer, type indicates the type of the service primitives (see 7.3.2), and [parameter1,.] is the list of values
passed to the service primitives. The square brackets indicate that this parameter list may be empty.
7.3.2 Types of service primitives
Service primitives shall be of three generic types:
a) Service.Request
The request primitive shall be passed from the (N)-user (service user) to the (N)-layer (service provider) to
request initiation of the service.
b) Service.Indication
The indication primitive shall be passed from the (N)-layer to the (N)-user to indicate an internal (N)-layer
(or sublayer) event which is significant to the (N)-user. This event may be logically related to a remote
service request, or may be caused by an event internal to the (N)-layer (or sublayer).
c) Service.Confirm
The confirm primitive shall be passed from the (N)-layer (or sublayer) to the (N)-user to convey the results
of one or more associated previous service request(s). This primitive may indicate either failure to comply
or some level of compliance. It shall not necessarily indicate any activity at the remote peer interface.
7.4 LLC interface
The LLC sublayer shall offer two types of connectionless transmission services to the LLC user:
a) unacknowledged data transfer service;
b) unacknowledged remote data request service.
The interface service data sent from or to the user shall be as in 8.2.2. The messages sent between LLC user
and LLC sublayer shall be as shown in a) and b) of Table 1.
The LLC interface messages sent from and to the supervisor FCE shall be as in 13.1.3.
Table 1 — Messages between LLC user and LLC sublayer
a) Message sent from LLC user to LLC sublayer
User to LLC message Meaning
Reset_Request Request to set the node into an initial state
b) Messages sent from LLC sublayer to LLC user
LLC to user message Meaning
Reset_Response Response to the Reset_Request
Indicates the current status of the node, i.e. it signals whether or
Node_Status
not the node is in the bus-off state.
8 Description of LLC sublayer
8.1 General
The LLC sublayer describes the upper part of the OSI DLL. It is related with those protocol issues that are
independent of the type of medium access method.
8.2 Services of LLC sublayer
8.2.1 Types of connectionless-mode transmission services
The LLC sublayer shall offer two types of connectionless-mode transmission services:
a) Unacknowledged data transfer service
This service shall provide means by which LLC users exchange LSDU without establishing a data-link
connection. The data transfer may be point-to-point, multicast or broadcast.
b) Unacknowledged remote data request service
This service shall provide means used by an LLC user to request a remote node for an LSDU
transmission without establishing a data-link connection.
The remote node shall basically serve the data request in the following two ways:
1) The requested data may be prepared by the remote user for transmission. In this case the data shall
be located in a remote node buffer and shall be transmitted by the remote user LLC entity upon
reception of the remote request frame.
2) The requested data shall be transmitted by the remote user upon reception of the remote request
frame.
According to the two different LLC services, two types of frames sent from or to the user shall be used:
LLC data frame;
LLC remote frame.
The LLC data frame shall carry data from a transmitter to a receiver. The LLC remote frame shall be
transmitted to request transmission of a data frame (with the same identifier) from a (single) remote node. In
both cases, the LLC sublayer shall notify the successful transmission or reception of a frame to the user.
8.2.2 Service primitive specification
8.2.2.1 General
The service primitive specification of this subclause describes in detail the LLC service primitives and their
associated parameters. The complete list of LLC service primitives shall be as given in Table 2.
10 © ISO 2003 — All rights reserved
Table 2 — LLC service primitives overview
Unacknowledged data transfer service
L_Data.Request Request for data transfer
L_Data.Indication Indication of data transfer
L_Data.Confirm Confirm data transfer
Unacknowledged remote data request service
L_Remote.Request Request for remote data request
L_Remote.Indication Indication of remote data request
L_Remote.Confirm Confirmation remote data request
The parameters associated with the different LLC service primitives shall be as given in Table 3.
Table 3 — List of LLC service primitive parameters
LLC service primitive parameters
Identifier Identifies the data and its priority
DLC DLC
Data Data the user wants to transmit
Transfer_Status Confirmation parameter
8.2.2.2 L_Data.Request
8.2.2.2.1 Function
The L_Data.Request primitive shall be passed from the LLC user to the LLC sublayer to request that an LSDU
be sent to one or more remote LLC entities.
8.2.2.2.2 Semantics of L_Data.Request primitive
The primitive shall provide parameters as follows
L_Data.Request (
Identifier
DLC
Data
)
The parameter Data shall be insignificant if the associated LLC data frame is of data length zero.
8.2.2.2.3 Effect on receipt
Receipt of this primitive shall cause the LLC sublayer to initiate the transfer of an LLC data frame by use of the
data transfer service provided by the MAC sublayer (see Table 5).
8.2.2.3 L_Data.Indication
8.2.2.3.1 Function
The L_Data.Indication primitive shall be passed from the LLC sublayer to the LLC user to indicate the arrival
of an LSDU.
8.2.2.3.2 Semantics of L_Data.Indication primitive
The primitive shall provide parameters as follows
L_Data.Indication (
Identifier
DLC
Data
)
The parameter Data shall be insignificant if the associated LLC data frame is of data length zero.
8.2.2.3.3 Effect on receipt
The effect on receipt of this primitive by the LLC user is unspecified.
8.2.2.4 L_Data.Confirm
8.2.2.4.1 Function
The L_Data.Confirm primitive shall be passed from the local LLC sublayer to the LLC user to convey the
results of the previous L_Data.Request primitive. This primitive shall be a local confirmation, i.e. it shall not
imply that the remote LLC entity or entities have passed the associated indication primitive to the
corresponding LLC user(s).
8.2.2.4.2 Semantics of L_Data.Confirm primitive
The primitive shall provide parameters as follows:
L_Data.Confirm (
Identifier
Transfer_Status
)
The Transfer_Status shall be used to indicate the completion of the transaction initiated by the previous
L_Data.Request primitive.
Transfer_Status:[Complete, Not_Complete]
8.2.2.4.3 Effect on receipt
The effect on receipt of this primitive by the LLC user is unspecified.
8.2.2.5 L_Remote.Request
8.2.2.5.1 Function
The L_Remote.Request primitive shall be passed from the LLC user to the LLC sublayer to request a single
remote LLC entity to transmit an LSDU.
8.2.2.5.2 Semantics of L_Remote.Request primitive
The primitive shall provide parameters as follows:
L_Remote.Request (
Identifier
DLC
)
The value of DLC equals the length of the data field of the requested data frame.
12 © ISO 2003 — All rights reserved
8.2.2.5.3 Effect on receipt
Receipt of this primitive shall cause the LLC sublayer to initiate the transfer of an LSDU by use of the remote
data transfer service provided by the MAC sublayer (see Table 5).
8.2.2.6 L_Remote.Indication
8.2.2.6.1 Function
The L_Remote.Indication primitive shall be passed from the LLC sublayer to the LLC user to indicate the
arrival of a request for transmission of an LSDU.
8.2.2.6.2 Semantics of L_Remote.Indication primitive
The primitive shall provide parameters as follows:
L_Remote.Indication (
Identifier
DLC
)
The identifier shall identify the LSDU to be sent. The value of DLC equals the length of the data field of the
requested data frame.
8.2.2.6.3 Effect on receipt
The effect on receipt of this primitive by the LLC user is unspecified.
8.2.2.7 L_Remote.Confirm
8.2.2.7.1 Function
The L_Remote.Confirm primitive shall be passed from the local LLC sublayer to the LLC user to convey the
results of the previous L_Remote.Request primitive. This primitive shall be a local confirmation, i.e. it does not
imply that the remote LLC entity has passed the associated indication primitive to the corresponding LLC user.
8.2.2.7.2 Semantics of L_Remote.Confirm primitive
The primitive shall provide parameters as follows:
L_Remote.Confirm (
Identifier
Transfer_Status
)
The Transfer_Status shall be used to indicate the completion of the transaction initiated by the previous
L_Remote.Request primitive.
Transfer_Status:[Complete, Not_Complete]
8.2.2.7.3 Effect on receipt
The effect on receipt of this primitive by the LLC user is unspecified.
8.3 Functions of LLC sublayer
8.3.1 General
The LLC sublayer shall provide the following functions:
a) frame acceptance filtering;
b) overload notification;
c) recovery management.
8.3.2 Frame acceptance filtering
A frame transaction initiated at the LLC sublayer shall be a single, self-contained operation independent of
previous frame transactions. The content of a frame shall be named by its identifier. The identifier does not
indicate the destination of the frame but describes the meaning of the data. Each receiver may decide by
frame acceptance filtering whether the frame is relevant or not.
8.3.3 Overload notification
The transmission of a MAC overload frame shall be initiated by the LLC sublayer if internal conditions of a
receiver require delay of the next LLC data or LLC remote frame.
At most two MAC overload frames may be generated to delay the next data frame or remote frame.
8.3.4 Recovery management
The LLC sublayer shall provide the means for automatic retransmission of frames that have lost arbitration or
have been disturbed by errors during transmission (see 6.11). The frame transmission service shall not be
confirmed to the user before the transmission has been successfully completed.
8.4 Structure of LLC frames
8.4.1 General
LLC frames shall be the data units exchanged between peer LLC entities (LPDU). The structure and format of
the LLC data and remote frame shall be specified subsequently.
8.4.2 Specification of LLC data frame
8.4.2.1 General
An LLC data frame shall consist of three bit fields (see Figure 3):
identifier field;
DLC field;
LLC data field.
Figure 3 — LLC data frame
14 © ISO 2003 — All rights reserved
8.4.2.2 Identifier field
The identifier field shall be composed of three segments: base identifier, extension flag and identifier
extension. The length of the base identifier shall be eleven (11) bits (ID-28 to ID-18), the extension flag one bit,
and the length of the identifier extension shall be eighteen (18) bits (ID-17 to ID-0). The identifier extension
shall be ignored if the extension flag is logic zero (0).
8.4.2.3 DLC field
The number of bytes in the data field shall be indicated by the DLC (see Table 4). This DLC shall consist of
four (4) bits. The admissible number of data bytes for a data frame shall range from zero (0) to eight (8). DLCs
in the range of zero (0) to seven (7) shall indicate data fields of length of zero (0) to seven (7) bytes. All other
DLCs shall indicate that the data field is eight (8) bytes long.
8.4.2.4 Data field
The data field shall consist of the data to be transferred within a data frame. It may contain from zero (0) bytes
to eight (8) bytes, where each byte contains eight (8) bits.
8.4.3 Specification of LLC remote frame
An LLC remote frame shall be composed of two bit fields (see Figure 4):
identifier field;
DLC field.
Table 4 — Coding of the numbers of data bytes by the DLC
DLC
Number of data bytes
DLC3 DLC2 DLC1 DLC0
0 0 0 0 0
1 0 0 0 1
2 0 0 1 0
3 0 0 1 1
4 0 1 0 0
5 0 1 0 1
6 0 1 1 0
7 0 1 1 1
8 1 0 or 1 0 or 1 0 or 1
Figure 4 — LLC data frame
The formats of both the LLC remote frame identifier field and DLC field shall be identical to the formats of the
LLC data frame identifier field (see 8.4.2.2) and DLC field (see 8.4.2.3). There shall be no data field,
independent of the value of the DLC.
Remote frames may only be transmitted with a system-wide determined DLC, which is the DLC of the
corresponding data frame (see 10.8.8).
8.5 Limited LLC frames
The full range of possible identifiers or DLCs is not required to be implemented.
If an LLC sublayer is restricted to the use of a subrange of identifiers (e.g. only base identifiers), then it shall
be limited to LLC data frames and LLC remote frames with identifiers of that subrange (e.g. identifiers with
their extension flag set to logic 0 and their identifier extension ignored).
If an LLC sublayer is restricted to the use of less than eight (8) data bytes, then it shall be limited to LLC data
frames and LLC remote frames with DLCs of that restricted range.
9 Interface between LLC and MAC
9.1 Services
The MAC sublayer shall provide services to the local LLC for
(MAC-) acknowledged transfer of LLC frames, and
transmission of MAC overload frames.
The interface service data from or to the LLC sublayer shall be in accordance with 8.3.
9.2 TTC option
9.2.1 Description
The TTC option describes the prerequisites for the synchronization of all nodes in the network. With the
synchronization of node, any message may be transmitted at a specific time slot, where it has not to compete
for the bus with other messages thus providing predictable latency times by avoiding the loss of arbitration. In
order to synchronize the activities of the nodes within the network, a common reference point is needed. The
SOF bit or the sample point of the last bit of EOF of any message shall be used as the reference point. The
individual presence of a single message at a time shall be referred to as frame scheduling. Based on the
synchronization of the nodes, the TTC also facilitates the establishment of a global time system in higher-layer
protocols.
The hardware needed to establish TTC shall be included between LLC and MAC.
9.2.2 Time base
Any node that supports TTC option shall provide a time base. The time base is a cyclic up counter of at least
16 bits with either an internal or an external clock.
9.2.3 Time reference point
Any message received or transmitted shall invoke a capture of the time base taken at the SOF recognition of
the respective message or at the sample point of the last bit of EOF. After successful message reception, the
capture value shall be provided to the CPU for at least one message and shall be readable until the next
message is received.
9.2.4 Event generation
It shall be possible to generate at least one programmable event trigger from the above-mentioned time base.
×
The trigger shall be freely programmable by the CPU in the range of at least zero (0) to (2 − 1) timer
clocks.
16 © ISO 2003 — All rights reserved
9.2.5 Retransmission of frames
Disabling of the automatic retransmission shall be supported (see 6.11).
10 Description of MAC sublayer
10.1 General
The MAC sublayer represents the lower part of the OSI DLL. It shall service the interface to the LLC sublayer
and the PL, and comprise the functions and rules related to
encapsulation/decapsulation of the transmit/receive data,
error detection and signalling, and
management of the transmit/receive medium access.
10.2 Services of MAC sublayer
10.2.1 Service description
The services provided by the MAC sublayer shall allow the local LLC sublayer entity to exchange MSDU with
the peer LLC sublayer entities. The MAC sublayer services shall be the following.
a) Acknowledged data transfer
This service shall provide means by which LLC entities exchange MSDUs without the establishment of a
data link connection. The data transfer may be point-to-point, multicast or broadcast.
b) Acknowledged remote data request
This service shall provide the means by which an LLC entity can request another remote node to transmit
an LSDU without the establishment of a data-link connection. The remote LLC entity shall use the MAC
service “acknowledged data transfer” for the transmission of the request
...
NORME ISO
INTERNATIONALE 11898-1
Première édition
2003-12-01
Véhicules routiers — Gestionnaire de
réseau de communication (CAN) —
Partie 1:
Couche liaison de données et
signalisation physique
Road vehicles — Controller area network (CAN) —
Part 1: Data link layer and physical signalling
Numéro de référence
©
ISO 2003
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier
peut être imprimé ou visualisé, mais ne doit pas être modifié à moins que l'ordinateur employé à cet effet ne bénéficie d'une licence
autorisant l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées
acceptent de fait la responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute
responsabilité en la matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la création du présent fichier PDF sont disponibles dans la rubrique General Info
du fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir
l'exploitation de ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation,
veuillez en informer le Secrétariat central à l'adresse donnée ci-dessous.
© ISO 2003
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous
quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit
de l'ISO à l'adresse ci-après ou du comité membre de l'ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax. + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Version française parue en 2004
Publié en Suisse
ii © ISO 2003 – Tous droits réservés
Sommaire Page
Avant-propos. v
1 Domaine d'application. 1
2 Conformité . 1
3 Références normatives. 1
4 Termes et définitions . 2
5 Symboles et termes abrégés . 3
6 Concepts fondamentaux du CAN. 5
6.1 Propriétés du CAN . 5
6.2 Trames. 5
6.3 Méthode d'accès au bus. 5
6.4 Acheminement des informations . 5
6.5 Souplesse du système . 6
6.6 Cohérence des données. 6
6.7 Demande de données déportées. 6
6.8 Détection d'erreur . 6
6.9 Signalisation d'erreur et temps de récupération . 6
6.10 ACK. 6
6.11 Retransmission automatique. 6
6.12 Limitation des pannes . 7
6.13 Actif-erreur. 7
6.14 Passif-erreur . 7
6.15 Déconnecté du bus . 7
7 Architecture en couches du CAN. 7
7.1 Référence au modèle OSI. 7
7.2 Spécification de protocole . 8
7.3 Description du format des services . 9
7.4 Interface LLC . 10
8 Description de la sous-couche LLC. 10
8.1 Généralités. 10
8.2 Services de la sous-couche LLC. 10
8.3 Fonctions de la sous-couche LLC . 14
8.4 Structure des trames de la sous-couche LLC. 15
8.5 Trames LLC limitées . 17
9 Interface entre la sous-couche LLC et la sous-couche MAC . 17
9.1 Services. 17
9.2 Option TTC. 17
10 Description de la sous-couche MAC. 18
10.1 Généralités. 18
10.2 Services de la sous-couche MAC. 18
10.3 Modèle fonctionnel de l'architecture de la sous-couche MAC. 23
10.4 Structure des trames MAC. 25
10.5 Codage des trames . 31
10.6 Ordre de transmission des bits . 32
10.7 Validation d'une trame. 32
10.8 Méthode d'accès au support. 33
10.9 Détection d'erreur . 34
10.10 Signalisation des erreurs . 35
10.11 Signalisation de surcharge .35
10.12 Surveillance du bus.35
11 Conformité des sous-couches LLC et MAC .36
12 Couche physique (PL) .36
12.1 Généralités .36
12.2 Modèle fonctionnel de la couche physique.36
12.3 Services de la PL.37
12.4 Spécification de la sous-couche PLS.37
12.5 Spécification de l'interface PLS-PMA.42
13 Description du superviseur.42
13.1 Limitation des pannes .42
13.2 Gestion des défaillances du bus .47
Bibliographie.48
iv © ISO 2003 – Tous droits réservés
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiée
aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit de faire partie du
comité technique créé à cet effet. Les organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec
la Commission électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI,
Partie 2.
La tâche principale des comités techniques est d'élaborer les Normes internationales. Les projets de Normes
internationales adoptés par les comités techniques sont soumis aux comités membres pour vote. Leur
publication comme Normes internationales requiert l'approbation de 75 % au moins des comités membres
votants.
L'attention est appelée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO ne saurait être tenue pour responsable de ne
pas avoir identifié de tels droits de propriété et averti de leur existence.
L'ISO 11898-1 a été élaborée par le comité technique ISO/TC 22, Véhicules routiers, sous-comité SC 3,
Équipement électrique et électronique.
Cette première édition de l’ISO 11898-1, avec l’ISO 11898-2, annule et remplace l’ISO 11519-2:1994,
l’ISO 11898:1993 et son amendement ISO 11898:1993/Amd 1:1995, qui ont fait l'objet d'une révision
technique. Alors que l'ISO 11898:1993 couvrait la couche liaison de données (DLL) et la couche physique
(PL) à haute vitesse du CAN, l’ISO 11898-1 spécifie la DLL, y compris les sous-couches de contrôle de liaison
logique (LLC) et de contrôle d'accès au support (MAC), ainsi que la sous-couche de signalisation physique
(PLS), et l’ISO 11898-2 spécifie l'unité d'accès au support (MAU) à haute vitesse.
L'ISO 11898 comprend les parties suivantes, présentées sous le titre général Véhicules routiers —
Gestionnaire de réseau de communication (CAN):
Partie 1: Couche liaison de données et signalisation physique
Partie 2: Unité d’accès au support à haute vitesse
Partie 3: Interface dépendant du support, tolérant les défaillances, à basse vitesse
Partie 4: Déclenchement temporel des communications
NORME INTERNATIONALE ISO 11898-1:2003(F)
Véhicules routiers — Gestionnaire de réseau de communication
(CAN) —
Partie 1:
Couche liaison de données et signalisation physique
1 Domaine d'application
La présente partie de l'ISO 11898 spécifie la couche liaison de données (DLL) et la signalisation physique du
gestionnaire de réseau de communication (CAN): un protocole de communication série qui prend en charge la
commande répartie en temps réel et le multiplexage, pour les besoins des véhicules routiers. Elle décrit
l'architecture générale du CAN, en termes de couches hiérarchiques, conformément au modèle de référence
ISO pour l'interconnexion de systèmes ouverts (OSI) spécifié dans l'ISO/CEI 7498-1, et fournit les
caractéristiques de configuration d'un échange d'informations numériques entre modules par mise en œuvre
de la DLL du CAN — celle-ci étant spécifiée conformément à l'ISO/CEI 8802-2 et à l'ISO/CEI 8802-3 — avec
des spécifications détaillées de la sous-couche de contrôle de liaison logique (LLC) et de la sous-couche de
contrôle d'accès au support (MAC).
2 Conformité
La conformité de la DLL doit être vérifiée conformément à l'ISO 16845.
3 Références normatives
Les documents de référence suivants sont indispensables pour l'application du présent document. Pour les
références datées, seule l'édition citée s'applique. Pour les références non datées, la dernière édition du
document de référence s'applique (y compris les éventuels amendements).
ISO/CEI 7498-1, Technologies de l'information — Interconnexion de systèmes ouverts (OSI) — Modèle de
référence de base: Le modèle de base
ISO/CEI 8802-2, Technologies de l'information — Télécommunications et échange d'information entre
systèmes — Réseaux locaux et métropolitains — Exigences spécifiques — Partie 2: Contrôle de liaison
logique
ISO/CEI 8802-3, Technologies de l'information — Télécommunications et échange d'information entre
systèmes — Réseaux locaux et métropolitains — Prescriptions spécifiques — Partie 3: Accès multiple par
surveillance du signal et détection de collision (CSMA/CD) et spécifications pour la couche physique
ISO 16845, Véhicules routiers — Gestionnaire de réseau de communication (CAN) — Plan d'essai de
conformité
4 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s'appliquent.
4.1
débit binaire
nombre de bits par unité de temps au cours de la transmission, indépendant de la représentation des bits
4.2
bourrage de bits
remplissage avec des bits pour assurer les changements d'état du bus requis pour la resynchronisation
périodique en cas d'utilisation d'une représentation binaire sans retour à zéro
NOTE Chaque fois que la logique de transmission rencontre un certain nombre de bits consécutifs de valeur égale
dans les données (largeur de bourrage), elle bourre automatiquement un bit de valeur complémentaire – bit de bourrage –
dans le train de bits sortant. Les destinataires débourrent la trame, c'est-à-dire qu'ils effectuent la procédure inverse.
4.3
durée d'un bit
t
B
durée de transmission d'un bit
4.4
bus
topologie d'un réseau de communication dans lequel tous les nœuds sont atteints par des liaisons passives
qui permettent la transmission dans les deux sens
4.5
comparateur de bus
dispositif qui reconvertit des signaux physiques utilisés pour le transfert sur le support de communication en
informations logiques ou en signaux de données
4.6
gestionnaire de bus
dispositif qui convertit des informations ou des signaux de données en signaux physiques de telle sorte que
ces signaux puissent être transférés sur le support de communication
4.7
état du bus
un des deux états logiques complémentaires: dominant ou récessif
NOTE L'état dominant représente la logique 0, et l'état récessif représente la logique 1. Pendant la transmission
simultanée de bits dominants et récessifs, l'état résultant du bus est dominant. En l'absence de toute transmission en
cours, le bus est inactif. Pendant ce temps, il est dans l'état récessif.
4.8
arbitrage de collision
procédure d'arbitrage CSMA dans le cas où l'accès simultané de plusieurs nœuds aboutirait à une collision
4.9
trame
unité de données (PDU) (protocole de liaison de données) spécifiant la disposition et la signification de bits ou
de champs de bits dans la séquence de transfert sur le support de transmission
4.10
multidiffusion
adressage dans lequel une trame unique est adressée à un groupe de nœuds simultanément
NOTE La diffusion est un cas particulier de multidiffusion dans lequel une seule trame est adressée simultanément à
tous les nœuds.
2 © ISO 2003 – Tous droits réservés
4.11
multimaître
système cloisonné en plusieurs nœuds dans lequel chaque nœud peut temporairement commander l'action
d'autres nœuds
4.12
nœud
ensemble relié à un réseau de communication et capable de communiquer sur le réseau conformément à une
spécification de protocole de communication
NOTE Un nœud CAN est un nœud qui communique sur un réseau CAN.
4.13
sans retour à zéro
NRZ
méthode de représentation de signaux binaires (pendant la durée d'un seul et même bit le niveau du signal ne
change pas) dans laquelle un train de bits de même valeur logique ne produit aucun front
4.14
priorité
attribut d'une trame qui régit son classement lors d'un arbitrage, une priorité élevée augmentant la probabilité
pour une trame de remporter l'arbitrage
4.15
protocole
ensemble formel de conventions ou de règles d'échange d'informations entre les nœuds, incluant la
spécification de l'administration des trames, du transfert des trames et de la couche physique (PL)
4.16
destinataire
nœud, lorsqu'il n'est pas émetteur et que le bus n'est pas inactif
4.17
déclenchement temporel des communications
option dans laquelle une trame peut être transmise dans un intervalle de temps spécifique, assurant
également une synchronisation générale des horloges et permettant la désactivation de la retransmission
automatique des trames
4.18
émetteur
nœud qui envoie une trame de données ou une trame déportée et qui reste émetteur jusqu'à ce que le bus
soit de nouveau inactif ou que le nœud perde l'arbitrage
5 Symboles et termes abrégés
ACK accusé de réception (Acknowledgment)
BCH Bose-Chaudhuri-Hocquenghem
BR débit binaire (Bit Rate)
t durée d'un bit
B
CAN gestionnaire de réseau de communication (Controller Area Network)
CRC contrôle de redondance cyclique (Cyclic Redundancy Check)
CSMA accès multiple avec écoute de porteuse (Carrier Sense Multiple Access)
DLC code de longueur de données (Data Length Code)
DLL couche liaison de données (Data Link Layer)
EOF fin de trame (End of Frame)
FCE entité de limitation des pannes (Fault Confinement Entity)
IC circuit intégré (Integrated Circuit)
IDE indicateur d'extension d'identifiant (Identifier Extension Flag)
LAN réseau local (Local Area Network)
LLC contrôle de liaison logique (Logical Link Control)
LME entité de gestion des couches (Layer Management Entity)
LPDU unité de données du protocole LLC (LLC Protocol Data Unit)
LSB bit le moins significatif (Least Significant Bit)
LSDU unité de données de service LLC (LLC Service Data Unit)
MA accès au support (Medium Acces)
MAC contrôle d'accès au support (Medium Acces Control)
MAU unité d'accès au support (Medium Access Unit)
MDI interface dépendant du support (Medium Dependent Interface)
MPDU unité de données du protocole MAC (MAC Protocol Data Unit)
MSB bit le plus significatif (Most Significant Bit)
MSDU unité de données de service MAC (MAC Service Data Unit)
NRZ sans retour à zéro (Non-Return-to-Zero)
OSI interconnexion de systèmes ouverts (Open System Interconnection)
OVLD surcharge (Overload)
PCI informations de contrôle de protocole (Protocol Control Information)
PDU unité de donnés de protocole (Protocol Data Unit)
PL couche physique (Physical Layer)
PLS sous-couche de signalisation physique (Physical Layer Signalling)
PMA sous-couche de raccordement au support physique (Physical Medium Attachment)
REC compteur d'erreurs de réception (Receive Error Counter)
RTR demande de transmission déportée (Remote Transmission Request)
SDU unité de données de service (Service Data Unit)
4 © ISO 2003 – Tous droits réservés
SJW largeur de saut de synchronisation (Synchronisation Jump Width)
SOF début de trame (Start of Frame)
SRR demande de substitution déportée (Substitute Remote Request)
TEC compteur d'erreurs de transmission (Transmit Error Counter)
TTC déclenchement temporel des communications (Time Triggered Communication)
6 Concepts fondamentaux du CAN
6.1 Propriétés du CAN
Le CAN doit posséder les propriétés suivantes:
accès multimaître au bus selon la priorité;
arbitrage non destructif en cas de collision;
transfert de trame multidiffusion par filtrage d'acceptation;
demande de données déportées;
souplesse de la configuration;
cohérence des données à l'échelle du système;
détection d'erreur et signalisation d'erreur;
retransmission automatique des trames qui ont perdu l'arbitrage ou qui ont été détruites par des erreurs
en cours de transmission;
distinction entre erreurs temporaires et défaillances permanentes des nœuds et coupure autonome des
nœuds défectueux.
6.2 Trames
Les informations sur le bus doivent être envoyées dans des trames de format fixe et de longueurs différentes
mais limitées. Lorsque le bus est inactif, tout nœud connecté peut commencer à transmettre une nouvelle
trame.
6.3 Méthode d'accès au bus
Lorsque le bus est inactif, tout nœud peut commencer à transmettre une trame. Si deux ou plusieurs nœuds
commencent à transmettre des trames simultanément, le conflit d'accès au bus doit être résolu par un
processus d'arbitrage de collision utilisant l'identifiant. Le mécanisme d'arbitrage doit prévenir toute perte
d'information et de temps. L'émetteur dont la trame a la priorité la plus élevée doit remporter l'accès au bus.
6.4 Acheminement des informations
Dans les systèmes CAN, un nœud ne doit utiliser aucune information sur la configuration du système (par
exemple adresse du nœud). Au lieu de cela, les destinataires acceptent ou n'acceptent pas l'information en
recourant à un processus appelé filtrage d'acceptation des trames, qui décide si l'information reçue est
pertinente ou non. Les destinataires n'ont pas besoin de connaître l'émetteur de l'information et vice versa.
6.5 Souplesse du système
Des nœuds peuvent être ajoutés au réseau CAN sans qu'il soit nécessaire de modifier le logiciel ou le
matériel d'un nœud quelconque si le nœud ajouté n'est pas l'émetteur d'une trame de données et s'il n'a pas
besoin de données transmises supplémentaires.
6.6 Cohérence des données
À l'intérieur d'un réseau CAN, une trame doit être acceptée simultanément soit par tous les nœuds, soit par
aucun d'entre eux. La cohérence des données est donc une propriété du système que l'on obtient par
application des concepts de multidiffusion et de traitement des erreurs.
6.7 Demande de données déportées
En envoyant une trame déportée, un nœud qui a besoin de données peut demander à un autre nœud
d'envoyer la trame de données correspondante. La trame de données et la trame déportée correspondante
doivent être désignées par le même identifiant.
6.8 Détection d'erreurs
Pour la détection des erreurs, les dispositions suivantes doivent être prévues:
surveillance (les émetteurs comparent le niveau des bits à transmettre au niveau des bits observés sur le
bus);
CRC sur 15 bits;
bourrage de bits variable avec une largeur de bourrage de 5;
contrôle de trame;
contrôle d'accusé de réception.
6.9 Signalisation d'erreur et temps de récupération
Les trames corrompues doivent être signalées par tout nœud émetteur et par tout nœud destinataire
fonctionnant normalement (actif-erreur). Ces trames doivent être abandonnées et retransmises conformément
à la procédure de récupération mise en œuvre (voir 8.3.4). Le temps de récupération qui s'écoule entre la
détection d'une erreur et le moment où le départ de la trame suivante est possible doit être généralement de
dix-sept (17) à vingt-trois (23) fois la durée d'un bit [jusqu'à trente et une (31) fois la durée d'un bit lorsque le
bus a été fortement perturbé] si d'autres erreurs n'apparaissent pas.
6.10 ACK
Tous les destinataires doivent contrôler la cohérence de la trame reçue; ils doivent accuser réception d'une
trame cohérente et signaler une trame incohérente. Une trame qui n'a pas fait l'objet d'un accusé de réception
est corrompue et elle doit être signalée par le nœud émetteur.
6.11 Retransmission automatique
Des trames qui ont perdu l'arbitrage ou qui ont été perturbées par des erreurs pendant la transmission doivent
être retransmises automatiquement lorsque le bus est redevenu inactif. Une trame qui doit être retransmise
doit être traitée comme n'importe quelle autre trame, c'est-à-dire qu'elle participe au processus d'arbitrage
pour obtenir l'accès au bus. En cas de déclenchement temporel des communications (TTC), la retransmission
automatique doit être désactivée (voir 9.2.5).
6 © ISO 2003 – Tous droits réservés
6.12 Limitation des pannes
Les nœuds du CAN doivent être capables de distinguer entre perturbations brèves et défaillances
permanentes. Les nœuds émetteurs défectueux doivent être coupés. Coupé signifie qu'un nœud est
logiquement déconnecté du bus de telle sorte qu'il ne peut ni envoyer, ni recevoir une trame (voir 13.1.4.3).
6.13 Actif-erreur
Un nœud actif-erreur doit prendre part normalement aux communications sur le bus et envoyer un indicateur
d'erreur actif en cas de détection d'une erreur. L’indicateur d'erreur actif doit être composé de six (6) bits
dominants consécutifs; il doit enfreindre la règle de bourrage des bits et tous les formats fixes qui
apparaissent dans une trame normale (voir 13.1.4.2).
6.14 Passif-erreur
Un nœud passif-erreur ne doit pas envoyer d’indicateur d'erreur actif. Il participe aux communications sur le
bus mais, en cas de détection d'une erreur, il doit envoyer un indicateur d'erreur passif. L’indicateur d'erreur
passif doit être composé de six (6) bits récessifs consécutifs. Après la transmission, un nœud passif-erreur
doit attendre pendant un délai supplémentaire avant de déclencher une nouvelle transmission (voir
«suspendre la transmission» en 10.4.6.4, et 13.1.4.2).
6.15 Déconnecté du bus
Un nœud doit être dans l'état déconnecté du bus lorsqu'il est coupé du bus à la suite d'une demande de la
FCE. Dans l'état déconnecté du bus, un nœud ne doit ni envoyer ni recevoir des trames. Un nœud ne doit
commencer sa restauration à partir de l'état déconnecté du bus que sur demande de l'utilisateur.
7 Architecture en couches du CAN
7.1 Référence au modèle OSI
Conformément au modèle de référence OSI, l'architecture du CAN de la présente partie de l’ISO 11898 doit
comporter deux couches,
la couche liaison de données (DLL), et
la couche physique (PL).
Voir Figure 1.
Conformément à l'ISO/CEI 8802-2 et à l'ISO/CEI 8802-3, la couche liaison de données (DLL) est subdivisée
en:
une sous-couche de contrôle de liaison logique (LLC), et
une sous-couche de contrôle d'accès au support (MAC).
La couche physique (PL) est subdivisée en:
une sous-couche de signalisation physique (PLS),
une sous-couche de raccordement au support physique (PMA), et
une interface dépendante du support (MDI).
Les opérations de la sous-couche MAC doivent être supervisées par une FCE. La limitation des pannes doit
être un mécanisme d'autocontrôle qui permet de distinguer les perturbations de courte durée des défaillances
permanentes (pour la limitation des pannes, voir 13.1).
La PL peut être supervisée par une entité qui détecte et gère les défaillances du support physique.
Figure 1 — Architecture en couches du CAN
7.2 Spécification de protocole
Deux entités de protocole homologues doivent communiquer entre elles en échangeant des trames ou des
PDU.
Une unité de données de protocole de la couche N (NPDU) doit consister en informations de contrôle de
protocole spécifiques de la couche N (N-PCI) et en des données de l'utilisateur (N). Pour transférer une
NPDU, il faut qu'elle soit transmise à une entité de la couche (N – 1) via un point d'accès de service
(N – 1) [(N – 1)-SAP]. La NPDU doit être transmise au moyen de l'unité de données de service de la couche
(N – 1) [(N – 1)-SDU] à la couche (N – 1) dont les services permettent le transfert de la NPDU. L'unité de
données de service doit correspondre aux données d'interface dont l'identité est préservée entre des entités
de la couche (N), c'est-à-dire qu'elle représente l'unité de données logique transférée par un service. La
couche liaison de données du protocole CAN ne doit donner aucun moyen de raccorder une SDU à des PDU
multiples et aucun moyen de raccorder des SDU multiples à une seule PDU, c'est-à-dire qu'une NPDU est
8 © ISO 2003 – Tous droits réservés
directement construite à partir de la NSDU associée et des informations de contrôle spécifiques de la couche
N-PCI. La Figure 2 illustre les interactions des sous-couches de liaison de données.
Figure 2 — Interactions des couches du protocole
7.3 Description du format des services
7.3.1 Description du format des primitives de services
Les primitives de services doivent s'écrire sous la forme:
service.type (
[paramètre1,.]
)
où service indique le nom du service, par exemple L_Data pour le service de transfert de données assuré par
la sous-couche LLC, type indique le type des primitives de services (voir 7.3.2), et [paramètre1,.] est la liste
des valeurs transmises aux primitives de services. Les crochets indiquent que cette liste de paramètres peut
être vide.
7.3.2 Types de primitives de services
Les primitives de services doivent être de trois types génériques:
a) Service.Request
La primitive de demande (request) doit être transmise de l'utilisateur (N) (utilisateur du service) à la
couche (N) (fournisseur du service) pour demander le déclenchement du service.
b) Service.Indication
La primitive d'indication doit être transmise de la couche (N) à l'utilisateur (N) pour indiquer un événement
interne de la couche (ou de la sous-couche) (N) important pour l'utilisateur (N). Cet événement peut être
logiquement associé à une demande de service déportée ou peut être causé par un événement interne
de la couche (ou de la sous-couche) (N).
c) Service.Confirm
La primitive de confirmation doit être transmise de la couche (ou de la sous-couche) (N) à l'utilisateur (N)
pour acheminer les résultats d'une ou de plusieurs demandes de services antérieures associées. Cette
primitive peut indiquer soit une non-conformité complète, soit un certain niveau de conformité. Elle ne doit
pas indiquer nécessairement une activité au niveau de l'interface homologue distante.
7.4 Interface LLC
La sous-couche LLC doit offrir à son utilisateur deux types de services de transmission sans connexion:
un service de transfert de données sans accusé de réception;
un service de demande de données déportées sans accusé de réception.
Les données de service de l'interface venant de l'utilisateur ou allant vers l’utilisateur doivent être comme
décrit en 8.2.2. Les messages échangés entre la sous-couche LLC et son utilisateur doivent être comme
présenté en a) et b) du Tableau 1.
Les messages échangés entre l'interface LLC et la FCE du superviseur doivent être comme décrit en 13.1.3.
Tableau 1 — Messages entre l'utilisateur LLC et la sous-couche LLC
a) Message envoyé par l'utilisateur LLC vers la sous-couche LLC
Message de l'utilisateur à la LLC Signification
Reset_Request Demande de réinitialisation du nœud
b) Messages envoyés de la sous-couche LLC vers l'utilisateur LLC
Message de la LLC à l'utilisateur Signification
Reset_Response Réponse à la demande Reset_Request
Indique l'état courant du nœud, c'est-à-dire signale si le
Node_Status
nœud est ou non dans l'état déconnecté du bus
8 Description de la sous-couche LLC
8.1 Généralités
La sous-couche LLC représente la partie supérieure de la couche liaison de données (DLL) OSI. Elle est
concernée par les questions de protocole qui sont indépendantes du type de méthode d'accès au support.
8.2 Services de la sous-couche LLC
8.2.1 Types de services de transmission sur le mode sans connexion
La sous-couche LLC doit offrir les deux types suivants de services de transmission sur le mode sans
connexion.
a) Service de transfert de données sans accusé de réception
Ce service doit permettre aux utilisateurs de la sous-couche LLC d'échanger des LSDU sans qu'une
connexion de liaison de données soit établie. Le transfert de données peut se faire par liaison point à
point, par multidiffusion ou par diffusion générale.
10 © ISO 2003 – Tous droits réservés
b) Service de demande de données déportées sans accusé de réception
Ce service doit permettre à un utilisateur de la sous-couche LLC de demander à un nœud distant de
transmettre une LSDU sans qu'une connexion de liaison de données soit établie.
Le nœud distant doit gérer la demande de données suivant les deux méthodes suivantes:
1) Les données demandées peuvent être préparées par l'utilisateur distant pour la transmission. En
pareil cas, les données doivent être placées dans une mémoire tampon du nœud distant et doivent
être transmises par l'entité LLC de l'utilisateur distant dès réception de la trame de demande
déportée.
2) Les données demandées doivent être transmises par l'utilisateur distant dès réception de la trame de
demande déportée.
Selon celui des deux services LLC qui est concerné, l'utilisateur doit envoyer ou recevoir deux types de
trames:
une trame de données LLC,
une trame déportée LLC.
La trame de données LLC doit acheminer des données d'un émetteur vers un destinataire. La trame déportée
LLC doit être transmise pour demander la transmission d'une trame de données (possédant le même
identifiant) à partir d'un nœud distant (et d'un seul). Dans les deux cas, la sous-couche LLC doit aviser
l'utilisateur de la réussite de la transmission ou de la réception d'une trame.
8.2.2 Spécification des primitives de services
8.2.2.1 Généralités
La spécification des primitives de services du présent paragraphe décrit en détail les primitives de services de
la sous-couche LLC et les paramètres qui leur sont associés. La liste complète des primitives de services LLC
doit être celle énumérée au Tableau 2.
Tableau 2 — Vue d'ensemble des primitives de services de la sous-couche LLC
Service de transfert de données sans accusé de réception
L_Data.Request Demande de transfert de données
L_Data.Indication Indication de transfert de données
L_Data.Confirm Confirmation de transfert de données
Service de demande de données déportées sans accusé de réception
L_Remote.Request Demande de demande de données déportées
L_Remote.Indication Indication de demande de données déportées
L_Remote.Confirm Confirmation de demande de données déportées
Les paramètres qui sont associés aux différentes primitives de services de la sous-couche LLC doivent être
ceux énumérés au Tableau 3.
Tableau 3 — Liste des paramètres des primitives de services de la sous-couche LLC
Paramètres des primitives de services de la sous-couche LLC
Identifier Identifie les données et leur priorité
DLC Code de longueur de données
Data Données que l'utilisateur veut transmettre
Transfer_Status Paramètre de confirmation
8.2.2.2 L_Data.Request
8.2.2.2.1 Fonction
La primitive L_Data.Request doit être transmise de l'utilisateur LLC vers la sous-couche LLC pour demander
qu'une LSDU soit envoyée à une ou plusieurs entités LLC distantes.
8.2.2.2.2 Sémantique de la primitive L_Data.Request
La primitive doit fournir les paramètres suivants:
L_Data.Request (
Identifier
DLC
Data
)
Le paramètre Data doit être sans objet si la trame de données LLC associée a une longueur de données
égale à zéro.
8.2.2.2.3 Effet à réception
À la réception de cette primitive, la sous-couche LLC doit déclencher le transfert d'une trame de données LLC
en utilisant le service de transfert de données assuré par la sous-couche MAC (voir Tableau 5).
8.2.2.3 L_Data.Indication
8.2.2.3.1 Fonction
La primitive L_Data.Indication doit être transmise de la sous-couche LLC vers l'utilisateur pour indiquer
l'arrivée d'une LSDU.
8.2.2.3.2 Sémantique de la primitive L_Data.Indication
La primitive doit fournir les paramètres suivants:
L_Data.Indication (
Identifier
DLC
Data
)
Le paramètre Data doit être sans objet si la trame de données LLC associée a une longueur de données
égale à zéro.
12 © ISO 2003 – Tous droits réservés
8.2.2.3.3 Effet à réception
L'effet de la réception de cette primitive par l'utilisateur LLC n'est pas spécifié.
8.2.2.4 L_Data.Confirm
8.2.2.4.1 Fonction
La primitive L_Data.Confirm doit être transmise de la sous-couche LLC locale vers l'utilisateur de cette sous-
couche pour acheminer les résultats de la primitive L_Data.Request précédente. Cette primitive doit être une
confirmation locale, c’est-à-dire qu’elle ne doit pas impliquer que l'entité ou les entités LLC distantes ont
transmis la primitive d'indication associée à l'utilisateur ou aux utilisateurs LLC correspondants.
8.2.2.4.2 Sémantique de la primitive L_Data.Confirm
La primitive doit fournir les paramètres suivants:
L_Data.Confirm (
Identifier
Transfer_Status
)
Le paramètre Tranfer_Status doit être utilisé pour indiquer l'achèvement de la transaction déclenchée par la
primitive L_Data.Request précédente.
Transfer_Status:[Complete, Not_Complete]
8.2.2.4.3 Effet à réception
L'effet de la réception de cette primitive par l'utilisateur LLC n'est pas spécifié.
8.2.2.5 L_Remote.Request
8.2.2.5.1 Fonction
La primitive L_Remote.Request doit être transmise de l'utilisateur LLC vers la sous-couche LLC pour
demander à une seule entité LLC distante de transmettre une LSDU.
8.2.2.5.2 Sémantique de la primitive L_Remote.Request
La primitive doit fournir les paramètres suivants:
L_Remote.Request (
Identifier
DLC
)
La valeur de DLC correspond à la longueur du champ de données de la trame de données demandée.
8.2.2.5.3 Effet à réception
À la réception de cette primitive, la sous-couche LLC doit déclencher le transfert d'une LSDU en utilisant le
service de transfert de données déportées assuré par la sous-couche MAC (voir Tableau 5).
8.2.2.6 L_Remote.Indication
8.2.2.6.1 Fonction
La primitive L_Remote.Indication doit être transmise de la sous-couche LLC vers l'utilisateur LLC pour
indiquer l'arrivée d'une demande de transmission d'une LSDU.
8.2.2.6.2 Sémantique de la primitive L_Remote.Indication
La primitive doit fournir les paramètres suivants:
L_Remote.Indication (
Identifier
DLC
)
L'identifiant doit identifier la LSDU à envoyer. La valeur de DLC correspond à la longueur du champ de
données de la trame de données demandée.
8.2.2.6.3 Effet à réception
L'effet de la réception de cette primitive par l'utilisateur LLC n'est pas spécifié.
8.2.2.7 L_Remote.Confirm
8.2.2.7.1 Fonction
La primitive L_Remote.Confirm doit être transmise de la sous-couche LLC locale vers l'utilisateur LLC pour
acheminer les résultats de la primitive L_Remote.Request précédente. Cette primitive doit être une
confirmation locale, elle ne doit pas impliquer que l'entité LLC distante a transmis la primitive d'indication
associée à l'utilisateur LLC correspondant.
8.2.2.7.2 Sémantique de la primitive L_Remote.Confirm
La primitive doit fournir les paramètres suivants:
L_Remote.Confirm (
Identifier
Transfer_Status
)
Le paramètre Transfer_Status doit être utilisé pour indiquer l'achèvement de la transaction déclenchée par la
primitive L_Remote.Request précédente.
Transfer_Status:[Complete, Not_Complete]
8.2.2.7.3 Effet à réception
L'effet de la réception de cette primitive par l'utilisateur LLC n'est pas spécifié.
8.3 Fonctions de la sous-couche LLC
8.3.1 Généralités
La sous-couche LLC doit assurer les fonctions suivantes:
a) filtrage d'acceptation des trames;
14 © ISO 2003 – Tous droits réservés
b) notification de surcharge;
c) gestion de la récupération.
8.3.2 Filtrage d'acceptation des trames
Une transaction de trame déclenchée au niveau de la sous-couche LLC doit être une opération unique,
autonome, indépendante des transactions de trames antérieures. Le contenu d'une trame doit être désigné
par son identifiant. L'identifiant n'indique pas la destination de la trame mais décrit la signification des données.
Chaque destinataire peut décider, par filtrage d'acceptation des trames, si la trame est pertinente ou non pour
ses besoins.
8.3.3 Notification de surcharge
La transmission d'une trame de surcharge de la sous-couche MAC doit être déclenchée par la sous-couche
LLC si l'état interne d'un destinataire exige de retarder les données suivantes ou la trame déportée suivante
de la sous-couche LLC.
Deux trames de surcharge de la sous-couche MAC peuvent être générées au maximum pour retarder la
trame de données ou la trame déportée suivante.
8.3.4 Gestion de la récupération
La sous-couche LLC doit donner la possibilité de retransmettre automatiquement des trames qui ont perdu un
arbitrage ou qui ont été perturbées par des erreurs pendant la transmission (voir 6.11). Le service de
transmission de trame ne doit être confirmé à l'utili
...
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...