ISO 11898-4:2004
(Main)Road vehicles - Controller area network (CAN) - Part 4: Time-triggered communication
Road vehicles - Controller area network (CAN) - Part 4: Time-triggered communication
ISO 11898-4:2004 specifies time-triggered communication in the controller area network (CAN): a serial communication protocol that supports distributed real-time control and multiplexing for use within road vehicles. It is applicable to setting up a time-triggered interchange of digital information between electronic control units (ECU) of road vehicles equipped with CAN, and specifies the frame synchronisation entity that coordinates the operation of both logical link and media access controls in accordance with ISO 11898-1, to provide the time-triggered communication schedule.
Véhicules routiers — Gestionnaire de réseau de communication (CAN) — Partie 4: Déclenchement temporel des communications
L'ISO 11898-4:2004 spécifie le déclenchement temporel des communications des gestionnaires 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 le besoin des véhicules routiers. Elle est applicable à la mise en place d'un échange d'informations numériques, avec déclenchement temporel, entre les unités de contrôle électronique (UCE) de véhicules routiers équipés d'un CAN, et spécifie l'entité de synchronisation des trames qui coordonne le fonctionnement du contrôle de liaison logique et du contrôle de l'accès au support, conformément à l'ISO 11898-1, pour produire un ordonnancement des communications par déclenchement temporel.
General Information
- Status
- Published
- Publication Date
- 04-Aug-2004
- Technical Committee
- ISO/TC 22/SC 31 - Data communication
- Drafting Committee
- ISO/TC 22/SC 31/WG 3 - In-vehicle networks
- Current Stage
- 9093 - International Standard confirmed
- Start Date
- 02-Jul-2025
- Completion Date
- 13-Dec-2025
Overview
ISO 11898-4:2004 - "Road vehicles - Controller area network (CAN) - Part 4: Time-triggered communication" defines a time-triggered communication option for the Controller Area Network (CAN) used in road vehicles. It specifies the frame synchronisation entity (FSE) and the mechanisms needed to build a deterministic, cyclic communication schedule across Electronic Control Units (ECUs). Time-triggered CAN is a higher-level protocol layer that leaves the underlying CAN protocol unchanged while providing predictable message latency independent of bus load.
Key topics and technical requirements
- Frame Synchronisation Entity (FSE): Coordinates logical link and media access controls to implement time-triggered behaviour; each CAN controller in a time-triggered CAN network has an FSE.
- Reference messages and time masters: A time master periodically sends a reference message to start a basic cycle; reference messages synchronise and calibrate local node clocks.
- Basic cycle, matrix cycle and time windows: Communication is organised as basic cycles subdivided into time windows and transmission columns forming a system matrix. Messages may be assigned to:
- Exclusive time windows (no bus competition)
- Arbitrating time windows (shared slots with arbitration)
- Levels of implementation:
- Level 1: Supports cyclic message transfer (cyclic scheduling).
- Level 2: Extends Level 1 by providing a global time across the network (local time + offset).
- Timing and synchronisation features: Local time generation, Cycle_Time, Cycle_Count and mechanisms for synchronisation, external clock synchronisation, and compensation for time discontinuities.
- Fault tolerance and redundancy: Procedures for time master initialisation, substitution of alternative time masters, failure handling (message status count, master state) and shutdown.
- Visible interfaces: Configuration, application and optional interfaces to manage triggers, message objects and status reporting.
Applications and who uses this standard
ISO 11898-4 is targeted at professionals implementing deterministic communication on CAN networks in road vehicles, including:
- Automotive OEMs and Tier-1 suppliers designing ECU networks
- Embedded systems and RTOS developers requiring cyclic, time-triggered messaging
- CAN controller and tool vendors implementing FSE functionality
- System integrators and safety-critical application engineers who need predictable latency and composability in distributed control systems
Typical applications include distributed real-time control where schedule predictability and composability are required (powertrain control, chassis systems, advanced driver-assistance systems where deterministic timing is important).
Related standards
- ISO 11898-1: Data link layer and physical signalling (required reference)
- ISO 11898-2: High-speed medium access unit
- ISO 11898-3: Low-speed fault-tolerant, medium dependent interface
Keywords: ISO 11898-4, Time-triggered CAN, CAN, controller area network, ECU, frame synchronisation, time master, basic cycle, system matrix, Level 1, Level 2, global time.
ISO 11898-4:2004 - Road vehicles — Controller area network (CAN) — Part 4: Time-triggered communication Released:8/5/2004
ISO 11898-4:2004 - Véhicules routiers — Gestionnaire de réseau de communication (CAN) — Partie 4: Déclenchement temporel des communications Released:8/5/2004
Frequently Asked Questions
ISO 11898-4:2004 is a standard published by the International Organization for Standardization (ISO). Its full title is "Road vehicles - Controller area network (CAN) - Part 4: Time-triggered communication". This standard covers: ISO 11898-4:2004 specifies time-triggered communication in the controller area network (CAN): a serial communication protocol that supports distributed real-time control and multiplexing for use within road vehicles. It is applicable to setting up a time-triggered interchange of digital information between electronic control units (ECU) of road vehicles equipped with CAN, and specifies the frame synchronisation entity that coordinates the operation of both logical link and media access controls in accordance with ISO 11898-1, to provide the time-triggered communication schedule.
ISO 11898-4:2004 specifies time-triggered communication in the controller area network (CAN): a serial communication protocol that supports distributed real-time control and multiplexing for use within road vehicles. It is applicable to setting up a time-triggered interchange of digital information between electronic control units (ECU) of road vehicles equipped with CAN, and specifies the frame synchronisation entity that coordinates the operation of both logical link and media access controls in accordance with ISO 11898-1, to provide the time-triggered communication schedule.
ISO 11898-4:2004 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.
You can purchase ISO 11898-4:2004 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-4
First edition
2004-08-01
Road vehicles — Controller area network
(CAN) —
Part 4:
Time-triggered communication
Véhicules routiers — Gestionnaire de réseau de communication
(CAN) —
Partie 4: Déclenchement temporel des communications
Reference number
©
ISO 2004
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 2004
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 2004 – All rights reserved
Contents Page
Foreword. iv
Introduction . v
1 Scope. 1
2 Normative references. 1
3 Terms and definitions. 1
4 Abbreviated terms. 6
5 Basic concepts of time-triggered CAN . 6
5.1 General conventions. 6
5.2 General principle of protocol. 8
5.3 Reference message. 10
6 Timing and synchronisation features . 12
6.1 Levels 1 and 2. 12
6.2 Generation of local time . 12
6.3 Cycle_Time parameter. 14
6.4 Synchronisation in Level 2. 14
6.5 Global time in Level 2 (local time + local offset). 14
6.6 External clock synchronisation. 15
7 Sending and receiving. 15
7.1 General. 15
7.2 Transmission of messages. 15
7.3 Reception of messages. 17
7.4 Transmission of reference messages. 17
8 Initialisation and fault tolerance of time masters .18
8.1 General. 18
8.2 Initialisation procedure. 19
8.3 Failure of current time master . 20
8.4 Shutdown. 20
9 Failure handling. 21
9.1 General. 21
9.2 Message status count. 22
9.3 Interrupt_Status_Vector. 22
9.4 Master state. 23
10 Visible interfaces. 25
10.1 Configuration interfaces. 25
10.2 Application interfaces. 28
10.3 Optional interfaces. 30
Bibliography . 32
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-4 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,
Electrical and electronic equipment.
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
iv © ISO 2004 – All rights reserved
Introduction
In the classic CAN network, communication is event-triggered; peak loads can occur when the transmission of
several messages is requested at the same time. The non-destructive arbitration mechanism of CAN
guarantees the sequential transmission of all messages according to their identifier priority. For hard real-time
systems, a scheduling analysis of the entire system is done to ensure that all transmission deadlines are met
even at peak bus loads.
Some real-time operating systems (RTOS) are based on static cyclic scheduling of all tasks in the application
system (control unit). They build a schedule of time slots and place each task in at least one slot. Tasks of
high priority appear in more than one slot. All activity in one slot, including interrupt handling, must be
completed before the beginning of the next slot.
If such an RTOS is considered for a distributed application system consisting of control units linked by a CAN
network, system integration and composability are served when the communication on the CAN network also
follows a synchronised schedule.
The time-triggered communication option for CAN-based networks (see ISO 11898-1) gives the prerequisites
for the synchronisation of all nodes in the CAN network. When the nodes are synchronised, any message may
be transmitted at a specific time slot, without competing with other messages for the bus. Thus the loss of
arbitration is avoided; the latency time becomes predictable.
INTERNATIONAL STANDARD ISO 11898-4:2004(E)
Road vehicles — Controller area network (CAN) —
Part 4:
Time-triggered communication
1 Scope
This part of ISO 11898 specifies time-triggered communication in the controller area network (CAN): a serial
communication protocol that supports distributed real-time control and multiplexing for use within road
vehicles. It is applicable to setting up a time-triggered interchange of digital information between electronic
control units (ECU) of road vehicles equipped with CAN, and specifies the frame synchronisation entity that
coordinates the operation of both logical link and media access controls in accordance with ISO 11898-1, to
provide the time-triggered communication schedule.
NOTE Time-triggered CAN is a higher level protocol layer additional to the CAN protocol itself, which remains
unchanged within the time-triggered communication. Time-triggered communication keeps the latency time of each
message at a specified value independent of the CAN bus load. Time-triggered CAN is implemented on two levels:
Level 1 is restricted to the cyclic message transfer, while Level 2, in addition, supports a global system time. Time-
triggered CAN’s cyclic, periodical communication is based on reference messages transmitted by a time master. Each
period starting with a reference message is called a basic cycle and is subdivided into several time windows. The
reference messages are used to synchronise and calibrate the time bases of all nodes to the time master's time base,
providing a global time for the network. A mechanism is provided for alternative time masters to substitute for a failing time
master.
2 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 11898-1, Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical
signalling
ISO 11898-2, Road vehicles — Controller area network (CAN) — Part 2: High-speed medium access unit
ISO 11898-3, Road vehicles — Controller area network (CAN) — Part 3: Low-speed fault-tolerant, medium
dependant interface
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 11898-1, ISO 11898-2 and
ISO 11898-3, and the following apply.
NOTE Parameter terms (Cycle_Time, Cycle_Count, etc.) are given as proper nouns, connected by an underscore
where the parameter consists of two or more words.
3.1
application watchdog
entity which verifies that the application is operating properly
3.2
arbitrating time window
time window assigned to messages that share the same time window
3.3
basic cycle
row of the system matrix of several consecutive time windows
3.4
Cycle_Time
difference between the local time of an FSE and its Ref_Mark
3.5
Cycle_Count
number of the current basic cycle of the matrix cycle
3.6
Cycle_Count_Max
value of Cycle_Count of the last basic cycle in the given system matrix of the network
3.7
Cycle_Offset
parameter specifying, within a matrix cycle, the first basic cycle for which an Rx_Trigger or Tx_Trigger is valid
3.8
Disc_Bit
part of the reference message signalling a discontinuity in global time caused by an external clock correction
by the time master
3.9
error severity
levels of distinguished severity of an error
3.10
exclusive time window
time window assigned to a specific message transmitted periodically without competition for the CAN bus
3.11
Expected_Tx_Trigger
local parameter which specifies, for each FSE, the number of Tx_Triggers the FSE is expected to activate
between two starts of a matrix cycle
3.12
Frame_Synchronisation
pulse, generated in each FSE and for each data frame and remote frame in the CAN network at the sample
point of start of frame (SOF) bit, synchronous in the whole network, disregarding signal propagation times,
and with an optionally added time offset referencing to the sync_segment of the SOF-Bit, to compensate for
variations of bit timing configuration in the system
3.13
frame synchronisation entity
FSE
part coordinating the operation of logical link control and media access control
NOTE Each CAN controller in a time-triggered CAN network has its own FSE.
2 © ISO 2004 – All rights reserved
3.14
free time window
time window free of messages scheduled in the system matrix
3.15
global time
node view of the global time of the current time master
3.16
Global_Ref_Mark
parameter saved on successful reception of a reference message
3.17
Global_Sync_Mark
current value of the node view of global time, saved at the pulse of Frame_Synchronisation
3.18
Init_Watch_Trigger
value of the maximum of cycle time
3.19
Initial_Ref_Offset
initialisation value that loads the Ref_Trigger_Offset
3.20
level
level of implementation of time-triggered CAN in accordance with this part of ISO 11898
NOTE There are two levels, Level 1 and Level 2, with Level 2 an extension of Level 1.
3.21
local time
time generated by a cyclic incrementing counter
3.22
Local_Offset
difference between Global_Ref_Mark and Ref_Mark, saved at each successful completion of the reference
message
3.23
master state
vector which combines the FSE states referring to error, synchronisation and master-slave relation, i.e. a
triplet (error level, sync_mode, master-slave_mode)
3.24
Master_Ref_Mark
MRM
parameter transmitted by the time master in the reference message
3.25
matrix cycle
cycle of all basic cycles in the system matrix, consecutive from the first to the last basic cycle
NOTE The matrix cycle is the same as the basic cycle if the system matrix consists of one basic cycle only.
3.26
merged arbitrating time window
single window into which consecutive arbitrating time windows are merged
3.27
message object
buffer providing storage of an LLC frame together with control and status information
3.28
message status count
MSC
error counter providing means for detecting scheduling errors for messages sent in exclusive time windows
3.29
network time unit
NTU
unit measuring all times and providing a constant of the whole network
3.30
network view
system aspect of network parameter
3.31
node view
local aspect of network parameter
3.32
node view of global time
integer part of the sum of local time of the node and its Local_Offset
3.33
potential time master
frame synchronisation entity that is allowed to send a reference message by system configuration
3.34
Ref_Mark
parameter saved on each successful completion of the reference message
3.35
Ref_Trigger_Offset
parameter used to modify the time mark within a Tx_Ref_Trigger such that it sends a reference message
3.36
reference message
message (data frame) that starts a basic cycle
3.37
Repeat_Factor
parameter specifying the repetition rate of a message within a transmission column, being a part of Tx_Trigger
or Rx_Trigger parameters
NOTE The unit of the repetition rate is “rows in the system matrix”.
3.38
Rx_Trigger
parameter that specifies when the successful reception of a message will be verified
3.39
Sync_Mark
current value of the local time saved at the pulse of Frame_Synchronisation
4 © ISO 2004 – All rights reserved
3.40
system matrix
form containing all messages of all nodes in the network, organised as components and consisting of time
windows organised in basic cycles (rows of the matrix) and transmission columns (columns of the matrix)
NOTE The system matrix specifies the correlation between messages and time windows (type and time mark). The
first basic cycle in the system matrix starts with Cycle_Count 0.
3.41
time gap
time between the end of a basic cycle and the beginning of the next basic cycle, when the beginning of the
next basic cycle is synchronised to an event
3.42
time mark
mark within a frame synchronisation entity specifying an instant of Cycle_Time (in NTUs) at which a certain
action is expected or planned
3.43
time master
frame synchronisation entity sending the reference message
3.44
time window
amount of time allocated for a specific transmission column in the system matrix
3.45
transmission column
column of the system matrix whose elements correlate to a particular time window repeated in each basic
cycle
NOTE Transmission rows are the basic cycles of the system matrix.
3.46
time unit ratio
TUR
ratio between the length of a NTU and the length of the FSE specific basic time unit (e.g. local oscillator
period) used for clock synchronisation
NOTE TUR is, in principle, a non-integer number. The node view of a NTU is implemented by the value of TUR.
3.47
Tx_Count
counter that is reset at each start of a matrix cycle, i.e. after identification of the corresponding reference
message with Cycle_Count equal to zero
3.48
Tx_Enable
time period within which the transmission of a message may be started
3.49
Tx_Overflow
status flag set when more Tx_Triggers occur than specified by Expected_Tx_Trigger
3.50
Tx_Ref_Trigger
special Tx_Trigger parameter referring only to the triggering of reference messages
3.51
Tx_Trigger
parameter specifying when a certain message will be transmitted and which consists of a time mark, the
position within the transmission column in respect of the first sending (Cycle_Offset) and the repetition rate
(Repeat_Factor) within that transmission column, and a reference to a message object for which the
Tx_Trigger is valid
NOTE The Tx_Trigger also contains information about the window type (exclusive, arbitrating, merged).
3.52
Tx_Underflow
status flag set when less Tx_Triggers occur than specified by Expected_Tx_Trigger
3.53
Watch_Trigger
time mark used to check whether the time since the last valid reference message has been too long
4 Abbreviated terms
CAN controller area network
FSE frame synchronisation entity
LLC logical link control
LSB least significant bit
MAC medium access control
MSB most significant bit
SOF start of frame
5 Basic concepts of time-triggered CAN
5.1 General conventions
For the purposes of this part of ISO 11898, the following conventions apply.
Application watchdog: regularly served by the Host_Alive_Sign parameter.
Arbitrating time window conflicts are resolved by the identifier arbitration of CAN and a CAN node may not
start transmission if the bus is not idle. Several CAN nodes in the network may start a transmission within the
Tx_Enable window of an arbitrating time window. The immediate automatic retransmission is disabled.
Exception: merging of time windows.
Basic cycle elements are several consecutive time windows. The number and length of the different time
windows is specified off-line and is the same for the whole network. Each basic cycle of the system matrix
consists of the same sequence of time windows, starting with the time window for the reference message.
Cycle_Time is truncated to the most significant 16 bits of the difference between the local time of a FSE and
its Ref_Mark, Cycle_Time = most significant 16 bits of (Local_Time – Ref_Mark).
Cycle_Count starts counting at zero.
Cycle_Offset is part of a Tx_Trigger or Rx_Trigger parameter.
6 © ISO 2004 – All rights reserved
Error severity: no error (S0), warning (S1), error (S2), and severe error (S3).
Expected_Tx_Trigger: when Tx_Count reaches Expected_Tx_Trigger, all further Tx_Triggers of this FSE in
the current matrix cycle are disabled.
FSE handles the transmission or reception of the time reference messages and provides a status and control
interface to the application layer.
Free time windows are reserved for future extensions of the network.
Global_Sync_Mark (Level 2 only) is saved at the pulse of Frame_Synchronisation. This value contains the
16-bit integer part as well as the fractional part of the sum (local time + local offset).
Init_Watch_Trigger has the value of 2 −1, the maximum of cycle time.
Local time is generated with a width of 16 bit in Level 1 and at least 19 bit in Level 2. All but the 16 most
significant bits in Level 2 give fractional parts of a NTU. The incrementation procedure of local time shall
guarantee that the non-fractional part is incremented once each local equivalent of NTU.
EXAMPLE If the fractional part uses 3 bits, local time is incremented eight times in Level 2, each increment being
the local equivalent of NTU/8.
Inside a merged arbitrating time window, the retransmission for frames that lost arbitration or were
disturbed by an error is enabled.
NTU is a constant of the whole network:
in Level 1, NTU is the nominal CAN bit time;
in Level 2, NTU is a fraction of the physical second.
Node view of global time is the integer part of the sum of local time of the node and its Local_Offset. The
fractional part is used for clock synchronisation only. Hence the node view of the global time is the local image
of the global time in (local) NTUs. It shall be possible to provide the node view of the global time as a
continuous monotonic value to the application.
Ref_Mark: at each successful completion of the reference message, the current Sync_Mark becomes
Ref_Mark.
Rx_Trigger: the necessary information for an Rx_Trigger consists of a time mark (point of time after which the
reception of the corresponding message is expected to be completed), the position within the transmission
column in respect to the first reception (Cycle_Offset) and the repetition rate (Repeat_Factor) within that
transmission column, and, of course, a reference to a message object for which the Rx_Trigger is valid.
Several Rx_Triggers may be specified for the same message. Rx_Triggers are intended for messages sent in
exclusive time windows only.
Time window: the three types of time window are exclusive, arbitrating and free.
TUR (Level 2 only) is used for clock synchronisation.
Tx_Count: each time a Tx_Trigger becomes active, Tx_Count is incremented. Tx_Count is not incremented
beyond Expected_Tx_Trigger.
Tx_Enable is opened with Tx_Trigger and closed after a predefined number of nominal CAN bit times
specified by the system configuration.
Watch_Trigger parameter value depends on the mode of operation (event synchronised or time-triggered) of
Time-triggered CAN.
5.2 General principle of protocol
5.2.1 System matrix — Matrix cycle
In a time-triggered system, all messages of all nodes in the network may be organised as components of a
system matrix. The system matrix specifies the correlation between the messages and the time windows in
which they shall be sent. In time-triggered CAN, the system matrix shall be organised in basic cycles (rows of
the matrix) and transmission columns (columns of the matrix). The number of basic cycles in the system
matrix shall be a power of two (2), its minimum value is 1. Each basic cycle starts with a specially
characterised message: the reference message (see Figure 1).
Figure 1 — Basic cycle of time-triggered CAN
Within a basic cycle, a message may be assigned to more than one time window, i.e. a specific message may
belong to more than one transmission column. The cycle of all basic cycles in the system matrix shall be the
matrix cycle. Within a matrix cycle, Cycle_Count shall count the number of the basic cycles. The counting
shall start at zero and shall end at Cycle_Count_Max. The current value of Cycle_Count shall be transmitted
by the time master as part of the reference message. In particular, it shall be cyclically incremented each
basic cycle by the time master. Any FSE receiving a valid reference message shall use the cycle count
transmitted in that reference message. The number of basic cycles within a matrix cycle
(Cycle_Count_Max+1) shall be an integer power of two (2).
A column of the matrix cycle is called a transmission column. Within a transmission column, a specific
message may be transmitted periodically with a period that is a power of two (2) that is not greater than the
number of rows in the system matrix. The unit of the period is “rows in the system matrix”. The number (as a
value of Cycle_Count) of the basic cycle in which this specific message is transmitted first is called
Cycle_Offset; the period is called Repeat_Factor. A specific message may belong to more than one
transmission column and may be transmitted in more than one time window of a transmission column.
5.2.2 Time windows
Each message shall be transmitted in a particular time window. Within a time window, the transmission of a
message may only be started during the Tx_Enable window (see 7.2.2), i.e. the SOF-bit of the message shall
be within the Tx_Enable window.
8 © ISO 2004 – All rights reserved
In time-triggered CAN, three different types of time windows shall be provided:
exclusive time windows;
free time windows;
arbitrating time windows.
A basic cycle may consist of time windows of different type and length. All time windows of a transmission
column shall have the same length but may have different types (see Figure 2, which shows a system matrix
with Cycle_Count_Max = 3).
Figure 2 — System matrix
Exclusive time windows are assigned to a specific message transmitted periodically without competition for
the CAN bus. Only one FSE in the network may start a transmission in an exclusive time window. Arbitrating
time windows are assigned to messages that share the same time window. Within arbitrating time windows,
bus conflicts are resolved by CAN identifier arbitration. Several FSEs in the network may start a transmission
in the arbitrating time window. In case of a lost arbitration, the automatic retransmission shall be disabled
(exception: merged arbitrating windows). Consecutive arbitrating time windows may be merged to one single
window. Frames that lost arbitration or were disturbed by an error may be retransmitted inside the merged
arbitrating time window. Free time windows are reserved for future extensions of the network.
NOTE For details concerning the Tx_Enable windows, see 7.2.2.
5.2.3 Event synchronised start of basic cycle
In a time-triggered system that is not event-synchronised, the reference messages shall be transmitted
periodically in equidistant time slots. Time-triggered CAN shall have the option to synchronise the basic cycles
to a specific event in the time masters’ nodes. When the communication is to be synchronised, the cyclic
message transfer shall be discontinued after the end of a basic cycle and a time gap may appear between the
end of the last periodic basic cycle and the beginning of the next, event-synchronised basic cycle. The time
gap shall be announced by the current time master in the last basic cycle’s reference message. The time gap
ends as soon as the current time master or one of the potential time masters sends a reference message to
start the following basic cycle of the matrix cycle. This is shown in Figure 3.
NOTE The event-synchronised start of a basic cycle can be used to synchronise the transmission cycles of two or
more time-triggered CAN busses.
Figure 3 — Event-synchronised basic cycle
5.3 Reference message
5.3.1 Description
All time-triggered, periodic communication on the CAN bus shall be based on the reference message. A
reference message shall be a data frame characterised by a specific CAN identifier and received and
accepted by all FSEs except the time master (sender of the reference message). For Level 1 the data length
code shall be at least one (1); for Level 2 the data length shall be at least four (4); otherwise, the message
shall not be accepted as reference message. All bits of the identifier except the three (3) LSBs characterise
the message as a reference message. The last 3 bits shall specify the priorities of up to 8 potential time
masters.
Both in Level 1 and in Level 2, the reference message shall contain the number of the current basic cycle
(Cycle_Count) and the status bit, Next_is_Gap, that announces whether the next cycle will begin with the
event-synchronised transmission of the reference message. In Level 2, the reference message shall
additionally contain the Master_Ref_Mark (measured in global time) and the status bit, Disc_Bit, that
announces whether there is a discontinuity in the global time. The time master shall transmit the reference
message, usually in equidistant time slots or optionally synchronised to a specific event. If the reference
message is disturbed by an error, it shall be possible for it to be retransmitted immediately. Note that, if
retransmission is disabled, there might no longer be any communication on the bus. In case of a
retransmission, the transmitted Master_Ref_Mark shall be updated. The reference message usually shall be
sent periodically, but it is permitted to stop the periodic transmission (Next_is_Gap bit) and to initiate event
synchronised at the start of the next basic cycle by the current time master or by one of the other potential
time masters.
The time master shall be the FSE transmitting the reference messages. The time master shall be allowed to
transmit other messages. If the current time master fails, its function shall be replicated by another FSE
10 © ISO 2004 – All rights reserved
belonging to the potential time masters. Each potential time master shall use a different specific CAN identifier
when it transmits a reference message, specified by its time master priority. Each of the specific CAN
identifiers shall be recognised by all FSEs in the network as a reference message identifier. FSEs that are
neither time master nor potential time master are time-receiving FSEs.
The reference message shall have different formats for Level 1 and Level 2 (see Figures 4 and 5). In both
cases, the reference message may be extended by other data up to the sum of eight CAN data bytes.
Reserved Bits shall be transmitted as logical 0 and shall be ignored by the receivers.
5.3.2 Level 1
The reference message for Level 1 shall consist of at least one data byte. The first byte contains Next_is_Gap
bit and the Cycle_Count. The MSB (bit number seven) is transmitted first. A time-triggered CAN FSE may be
able to deal with Cycle_Count values up to 63 (six bits). It is not necessary for a time-triggered CAN FSE to
support this.
NOTE FSEs with different value of supported Cycle_Count_Max may be used consistently in a time-triggered CAN
network. However it shall be guaranteed that all potential time masters of this network support the maximum value that is
used within the network by any of the FSEs.
7 6 5 4 3 2 1 0
Next_is_GapReserved Optional: Optional: Optional: Optional: Optional: Optional:
Cycle_Count (5) Cycle_Count (4)Cycle_Count (3)Cycle_Count (2) Cycle_Count (1) Cycle_Count (0)
Figure 4 — Format of reference message — Level 1
5.3.3 Level 2
The reference message for Level 2 shall consist of at least four data bytes (see Figure 5). The first byte shall
contain Next_is_Gap bit and the Cycle_Count. The MSB (bit 7) of each byte shall be transmitted first.
The second byte shall contain the discontinuity bit (Disc_Bit – see 6.6) and the bits for the network time unit
resolution (NTU_Res). These are the fractional parts of Master_Ref_Mark. In Level 2 at least three bits for
NTU_Res shall be supported, optionally a FSE may support additional bits up to a resolution of 7 bits. Bits that
are not supported shall be sent as logical 0.
The third byte shall contain the low byte of the Master_Ref_Mark (MRM), and the fourth byte the high byte of
the Master_Ref_Mark (MRM).
First byte
7 6 5 4 3 2 1 0
Next_is_Gap Reserved Optional: Optional: Optional: Optional: Optional: Optional:
Cycle_Count Cycle_Count Cycle_Count Cycle_Count Cycle_Count Cycle_Count
(5) (4) (3) (2) (1) (0)
Second byte
7 6 5 4 3 2 1 0
NTU_Res NTU_Res NTU_Res Optional: Optional: Optional: Optional: Disc_Bit
(6) (5) (4) NTU_Res NTU_Res NTU_Res NTU_Res
(3) (2) (1) (0)
Third byte
7 6 5 4 3 2 1 0
MRM MRM MRM MRM MRM MRM MRM MRM
(7) (6) (5) (4) (3) (2) (1) (0)
Fourth byte
7 6 5 4 3 2 1 0
MRM MRM MRM MRM MRM MRM MRM MRM
(15) (14) (13) (12) (11) (10) (9) (8)
Figure 5 — Format of reference message — Level 2
6 Timing and synchronisation features
6.1 Levels 1 and 2
There are two possible levels in time-triggered CAN: Level 1 and Level 2. Level 1 only provides time-triggered
operation using Cycle_Time. Level 2 shall additionally provide increased synchronisation quality, global time
and external clock synchronisation. In both levels, all timing features shall be based on a local time base —
the local time. In principle, all FSEs in the network shall measure their local times using the NTU. The node
view of the NTU usually differs marginally from the network view, owing to slight differences in the local
oscillators (system clocks). In Level 2, the synchronisation procedure shall ensure that these local views of a
NTU in different FSEs are very close (see 6.4). In Level 1, the NTU is the nominal CAN bit time; in Level 2, the
NTU is a fraction of the physical second.
It is possible to mix Level 1 and 2 FSEs within one time-triggered CAN network if the Level 2 NTU equals the
Level 1 NTU (nominal CAN bit time). However, all potential time masters shall be of Level 2 in such a mixed
network.
6.2 Generation of local time
In each FSE, local time shall be implemented by a cyclically incrementing counter. In Level 1, the counter
shall contain 16 bits, counting in units of a NTU (in Level 1 the nominal CAN bit time). In Level 2, the counter
shall contain at least 19 bits where all but the 16 most significant bits give fractional parts of a NTU, i.e. the
n
counter counts in units of NTU/2 if NTU_Res covers n bits. Hence, in Level 1 the counter shall increment
n
once each (local equivalent of an) NTU, while in Level 2 the counter shall increment 2 times each (local
equivalent of an) NTU. Apart from incrementing, local time shall be influenced only by hardware reset. In
hardware, each FSE shall have access to an oscillator which provides local clock ticks. The implementation of
a NTU in Level 2 shall be based on TUR.
12 © ISO 2004 – All rights reserved
NOTE TUR influences the length of a NTU, hence the velocity of the incrementing of local time.
TUR is a FSE-specific (usually non integer) number which gives the ratio between the length of a NTU and the
FSE-specific basic time unit. This FSE-specific basic time unit may be for instance the length of the oscillator
period. The local generation of an NTU shall be based on the local value of TUR that is currently valid:
TUR_Actual. The accuracy of TUR_Actual in the FSEs influences the maximum difference between any two
local views of a NTU. The value of TUR shall determine the length of a (local) NTU and thus the velocity of the
local time counter. Implementation of TUR as well as data format of TUR is FSE-specific.
NOTE 1 A Level 2 hardware implementation for the generation of a NTU can increment for instance the local time
counter 8 times every TUR_Actual clock ticks in (approximately) equidistant intervals. Since TUR is usually not an integer
number, the length of consecutive network time units could differ by one local oscillator period.
NOTE 2 In principle, it is possible to distinguish between different interpretations of the NTU, as follows.
a) Nominal NTU is the exact theoretical length of time of the NTU, which can be obtained or measured only by the
specified second. In practice, this is not achievable. However, the nominal NTU is of great importance as any
time-related specification will be recalculated into nominal NTUs in any application that takes advantage of the
common time in the system. The nominal NTU is thus a specification value that cannot be exactly met in reality. To
specify the global time, we give the number of nominal NTUs that make up a second.
b) Global NTU: the current time master will generate an internal time tick good enough for the complete system (i.e. the
network) to be used for its clock. The clock generates the global time for the system based on the global NTU.
Depending on the existence of an external clock synchronisation, the internal time “tick” of the current time master
will be replaced or influenced by an external clock source. The global NTU is represented by the current time
master’s node view of the NTU which is the network view of the NTU.
c) Local NTU: each node in a time-triggered CAN system has a local clock as a source for generating local time and
hence a local replica of the global time. As it receives the global time by the reference message from the time master,
this replica will deviate from the global time. How accurately it mirrors the global time is system-dependent;
essentially, the precision is given by the precision of TUR. The local NTU is the node view of a NTU.
Figure 6 shows a possible principle for the generation of the node view of a NTU.
The data format of TUR shall be implementation-specific for the FSE. The initialisation value of TUR within a
FSE (TUR_Config) is known a priori. FSEs that are not time master and that are synchronised to the time-
triggered CAN network shall continuously update their TUR value according to the observed ratio between
their local time (system clock) and the master’s global time (see 6.4).
Figure 6 — Generation of node view of NTU in Level 2
6.3 Cycle_Time parameter
A Frame_Synchronisation pulse shall be generated in each FSE for each data frame and remote frame in the
CAN network, at the sample point of the start of frame (SOF) bit. This pulse shall be synchronous in the whole
network, disregarding of signal propagation times. At the pulse of Frame_Synchronisation, the current value of
the local time shall be saved as the Sync_Mark. At each successful completion of the reference message, the
current Sync_Mark shall be saved as Ref_Mark.
The Cycle_Time shall be the difference between a FSE's local time and its Ref_Mark, conceptually restarting
with zero at each start of a basic cycle (Sync_Mark of the reference message). In fact, the starting point of
Cycle_Time may only be identified after completion of the reference message. In Level 2 only the 16 most
significant bits of this difference shall contribute to Cycle_Time, i.e. Cycle_Time has no fractional parts and
shall be always a 16-bit value both in Level 1 and Level 2. All time marks shall be given in the Cycle_Time
parameter.
6.4 Synchronisation in Level 2
In Level 2, an improved synchronisation of the different time counters between reference messages shall be
achieved by the adjustment of the TUR value, and TUR shall not usually be an integer number. In FSEs that
are not time master, TUR shall be adapted to the master’s view of the global time after each reception of the
reference message, compensating for clock drift.
At the pulse of Frame_Synchronisation, the current value of the node view of the sum of local time and local
offset shall be saved as the Global_Sync_Mark (node view of the global time including the fractional part).
This is a value of at least nineteen (19) bits. The time master shall transmit its current Global_Sync_Mark in
the reference message as Master_Ref_Mark. The current Master_Ref_Mark shall be saved, at each
successful completion of the reference message, as Global_Ref_Mark.
At each successful completion of the reference message, the difference between the node view of Ref_Mark
(in local time) and the Master_Ref_Mark of the reference message shall be saved as Local_Offset
(Local_Offset = Global_Ref_Mark – Ref_Mark). The Local_Offset may change due to oscillator drift. The
current time master view of Local_Offset shall remain constant; each node of the network shall start with a
Local_Offset of zero. When the current time master fails and another FSE (potential time master) becomes
time master, the new time master's Local_Offset shall be retained. A FSE that becomes the current time
master shall keep its updated TUR value. It may optionally support the feature to gradually return from the
TUR_Actual value to its TUR_Config value afterwards.
EXAMPLE Each time a reference message is completed, the current length of the last basic cycle is measured in
system clock periods (p_sys) and in global time (q_gt = difference between two Master_Ref_Marks in N
...
NORME ISO
INTERNATIONALE 11898-4
Première édition
2004-08-01
Véhicules routiers — Gestionnaire
de réseau de communication (CAN) —
Partie 4:
Déclenchement temporel
des communications
Road vehicles — Controller area network (CAN) —
Part 4: Time-triggered communication
Numéro de référence
©
ISO 2004
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 2004
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
Publié en Suisse
ii © ISO 2004 – Tous droits réservés
Sommaire Page
Avant-propos. iv
Introduction . v
1 Domaine d'application. 1
2 Références normatives. 1
3 Termes et définitions . 2
4 Termes abrégés. 6
5 Concepts fondamentaux du CAN à déclenchement temporel des communications . 7
5.1 Conventions générales. 7
5.2 Principe général du protocole . 8
5.3 Message de référence. 11
6 Caractéristiques de temporisation et de synchronisation . 13
6.1 Niveau 1 et niveau 2. 13
6.2 Génération du temps local. 13
6.3 Paramètre Cycle_Time. 15
6.4 Synchronisation au niveau 2 . 15
6.5 Temps global au niveau 2 (temps local + décalage local) . 16
6.6 Synchronisation horloge externe. 16
7 Envoi et réception . 16
7.1 Généralités. 16
7.2 Transmission de messages. 17
7.3 Réception de messages. 19
7.4 Transmission de messages de référence. 19
8 Initialisation et tolérance aux défaillances des horloges maîtresses . 20
8.1 Généralités. 20
8.2 Procédure d'initialisation. 21
8.3 Défaillance de l'horloge maîtresse courante. 22
8.4 Arrêt. 23
9 Gestion des défaillances. 23
9.1 Généralités. 23
9.2 Nombre d'état du message (MSC). 24
9.3 Interrupt_Status_Vector (vecteur d'état d'interruption). 25
9.4 État maître. 26
10 Interfaces visibles. 28
10.1 Interfaces de configuration. 28
10.2 Interfaces de l'application . 31
10.3 Interfaces optionnelles. 33
Bibliographie . 35
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-4 a été élaborée par le comité technique ISO/TC 22, Véhicules routiers, sous-comité SC 3,
Équipement électrique et électronique.
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
iv © ISO 2004 – Tous droits réservés
Introduction
Dans le réseau CAN classique, la communication est déclenchée par un événement; des charges maximales
peuvent survenir lorsque la transmission de plusieurs messages est demandée au même moment. Le
mécanisme d'arbitrage non destructif du CAN garantit la transmission séquentielle de tous les messages en
fonction de la priorité de leur identifiant. Pour les systèmes en temps réel câblés, une analyse
d'ordonnancement du système complet est effectuée pour garantir que tous les délais de transmission sont
respectés, même dans des conditions de charge maximale du bus.
Certains systèmes d'exploitation en temps réel sont fondés sur un ordonnancement cyclique statique de
toutes les tâches dans le système d'applications (unité de contrôle). Ils élaborent un ordonnancement de
créneaux de temps et placent chaque tâche dans un créneau au minimum. Les tâches de priorité élevée
apparaissent dans plus d'un créneau. Toute l'activité placée dans un créneau de temps, y compris le
traitement des interruptions, doit s'achever avant le début du créneau suivant.
Si un tel système d'exploitation en temps réel est envisagé pour un système d'applications réparties
consistant en unités de contrôle reliées par un réseau CAN, l'intégration et les possibilités de liaison du
système sont favorisées lorsque la communication sur le réseau CAN suit également un ordonnancement
synchronisé.
L'option de déclenchement temporel des communications pour les réseaux fondés sur un CAN (voir
l'ISO 11898-1) décrit les conditions préalables nécessaires à la synchronisation de tous les nœuds du réseau
CAN. Lorsque les nœuds sont synchronisés, tout message peut être transmis dans un créneau de temps
spécifique sans concurrencer les autres messages pour accéder au bus. La perte d'arbitrage est ainsi évitée,
le temps d'attente devient prévisible.
NORME INTERNATIONALE ISO 11898-4:2004(F)
Véhicules routiers — Gestionnaire de réseau de communication
(CAN) —
Partie 4:
Déclenchement temporel des communications
1 Domaine d'application
La présente partie de l'ISO 11898 spécifie le déclenchement temporel des communications des gestionnaires
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 le besoin des véhicules routiers. Elle est applicable à la mise
en place d'un échange d'informations numériques, avec déclenchement temporel, entre les unités de contrôle
électronique (UCE) de véhicules routiers équipés d'un CAN, et spécifie l'entité de synchronisation des trames
qui coordonne le fonctionnement du contrôle de liaison logique et du contrôle de l'accès au support,
conformément à l'ISO 11898-1, pour produire un ordonnancement des communications par déclenchement
temporel.
NOTE Le CAN à déclenchement temporel des communications est une couche de protocole de niveau supérieur
ajoutée au protocole CAN lui-même qui reste inchangé dans le cadre des communications à déclenchement temporel.
Les communications à déclenchement temporel maintiennent le temps d'attente de chaque message à une valeur
spécifiée indépendante de la charge du bus CAN. Un CAN à déclenchement temporel des communications est en œuvre
à deux niveaux. Le niveau 1 est limité exclusivement au transfert cyclique de messages, le niveau 2 assure en plus la
prise en charge d'un temps système global. Les communications cycliques et périodiques du CAN à déclenchement
temporel s'appuient sur des messages de référence transmis par une horloge maîtresse. Chaque période débutant par un
message de référence est appelée cycle de base et elle est subdivisée en plusieurs fenêtres de temps. Les messages de
référence sont utilisés pour synchroniser et étalonner les bases de temps de tous les nœuds d'après la base de temps de
l'horloge maîtresse, définissant un temps global pour le réseau. Il est prévu un mécanisme permettant à des horloges
maîtresses de rechange de remplacer une horloge maîtresse défectueuse.
2 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 11898-1, Véhicules routiers — Gestionnaire de réseau de communication (CAN) — Partie 1: Couche
liaison de données et signalisation physique
ISO 11898-2, Véhicules routiers — Gestionnaire de réseau de communication (CAN) — Partie 2: Unité
d'accès au support à haute vitesse
ISO 11898-3, Véhicules routiers — Gestionnaire de réseau de communication (CAN) — Partie 3: Interface
dépendant du support, tolérant les défaillances, à basse vitesse
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions donnés dans l'ISO 11898-1, l'ISO 11898-2 et
l'ISO 11898-3 ainsi que les suivants s'appliquent.
NOTE Les termes correspondant à des paramètres (Cycle_Time, Cycle_Count, etc.) commencent par une lettre
majuscule et sont reliés par un «_» si le paramètre est composé de deux mots ou plus.
3.1
chien de garde de l'application
entité servant à vérifier que l'application fonctionne correctement
3.2
fenêtre de temps d'arbitrage
fenêtre de temps affectée à des messages qui partagent la même fenêtre de temps
3.3
cycle de base
ligne de la matrice du système constituée de plusieurs fenêtres de temps consécutives
3.4
Cycle_Time
différence entre le temps local d'une entité de synchronisation des trames (FSE) et son paramètre Ref_Mark
3.5
Cycle_Count
numéro du cycle de base courant du cycle de la matrice
3.6
Cycle_Count_Max
valeur du paramètre Cycle_Count du dernier cycle de base dans la matrice système donnée du réseau
3.7
Cycle_Offset
paramètre précisant, à l'intérieur d'un cycle de la matrice, le premier cycle de base pour lequel un paramètre
Rx_Trigger ou Tx_Trigger est valide
3.8
Disc_Bit
partie du message de référence signalant une discontinuité du temps global survenue à la suite d'une
correction de l'horloge externe par l'horloge maîtresse
3.9
gravité de l'erreur
niveaux distincts de gravité d'une erreur
3.10
fenêtre de temps exclusive
fenêtre de temps affectée à un message spécifique transmis périodiquement sans concurrence pour l'accès
au bus CAN
3.11
Expected_Tx_Trigger
paramètre local qui définit, pour chaque entité de synchronisation des trames (FSE), le nombre prévu de
Tx_Trigger que la FSE va activer entre deux débuts d'un cycle de la matrice
2 © ISO 2004 – Tous droits réservés
3.12
Frame_Synchronisation
impulsion générée dans chaque entité de synchronisation des trames (FSE) pour chaque trame de données
et chaque trame distante dans le réseau CAN, au point d'échantillonnage du bit de début de trame (SOF),
synchrone sur l'ensemble du réseau quel que soit le temps de propagation des signaux; un décalage
temporel, faisant référence au paramètre Sync_Segment du bit SOF, peut être ajouté en option pour
compenser les variations de la configuration de synchronisation des bits dans le système
3.13
entité de synchronisation des trames
FSE
élément qui coordonne le fonctionnement du contrôle de liaison logique et du contrôle d'accès au support
NOTE Chaque contrôleur CAN d'un réseau CAN à déclenchement temporel des communications possède sa propre
FSE.
3.14
fenêtre de temps libre
fenêtre de temps ne contenant pas de messages, agencée dans la matrice du système
3.15
temps global
vue nodale du temps global de l'horloge maîtresse courante
3.16
Global_Ref_Mark
paramètre enregistré au moment de la réception correcte d'un message de référence
3.17
Global_Sync_Mark
valeur courante de la vue nodale du temps global, enregistrée au moment de l'impulsion de synchronisation
des trames, Frame_Synchronisation
3.18
Init_Watch_Trigger
valeur du maximum du temps de cycle
3.19
Initial_Ref_Offset
valeur d'initialisation pour charger le paramètre Ref_Trigger_Offset
3.20
niveau
niveau d'implémentation d'un CAN à déclenchement temporel conformément à la présente partie de
l'ISO 11898
NOTE Il existe deux niveaux, le niveau 1 et le niveau 2, le niveau 2 étant une extension du niveau 1
3.21
temps local
temps généré par un compteur à incrémentation cyclique
3.22
Local_Offset
différence entre Global_Ref_Mark et Ref_Mark, enregistrée à chaque achèvement correct du message de
référence
3.23
état maître
vecteur qui combine les états de l'entité de synchronisation des trames (FSE) se rapportant aux erreurs, à la
synchronisation et à la relation maître-esclave, c'est-à-dire un triplet (niveau d'erreur, Sync_Mode, Master-
Slave_Mode)
3.24
Master_Ref_Mark
MRM
paramètre transmis par l'horloge maîtresse dans le message de référence
3.25
cycle de la matrice
cycle de tous les cycles de base de la matrice du système, consécutifs du premier jusqu'au dernier cycle de
base
NOTE Le cycle de la matrice se confond avec le cycle de base si la matrice du système ne comporte qu'un seul
cycle de base.
3.26
fenêtre de temps d'arbitrage fusionnée
fenêtre unique où les fenêtres de temps d'arbitrage consécutives sont fusionnées
3.27
objet message
tampon assurant le stockage d'une trame de contrôle de liaison logique (LLC) avec des informations de
contrôle et d'état
3.28
nombre d'état du message
MSC
compteur d'erreur donnant les moyens de détecter des erreurs d'ordonnancement concernant des messages
envoyés dans des fenêtres de temps exclusives
3.29
unité de temps du réseau
NTU
unité permettant de mesurer tous les temps et fournissant une constante de l'ensemble du réseau
3.30
vue réseau
aspect système d'un paramètre du réseau
3.31
vue nodale
aspect local d'un paramètre du réseau
3.32
vue nodale du temps global
partie entière de la somme du temps local du nœud et de son décalage local, Local_Offset
3.33
horloge maîtresse potentielle
entité de synchronisation des trames (FSE) qui est autorisée à envoyer un message de référence par
configuration du système
3.34
Ref_Mark
paramètre enregistré à chaque achèvement correct du message de référence
4 © ISO 2004 – Tous droits réservés
3.35
Ref_Trigger_Offset
paramètre utilisé pour modifier la marque temporelle à l'intérieur d'un paramètre Tx_Ref_Trigger pour l'envoi
d'un message de référence
3.36
message de référence
message (trame de données) qui commence un cycle de base
3.37
Repeat_Factor
paramètre définissant la cadence de répétition d'un message à l'intérieur d'une colonne de transmission,
faisant partie des paramètres Tx_Trigger ou Rx_Trigger
NOTE L'unité de la cadence de répétition est «lignes de la matrice du système».
3.38
Rx_Trigger
paramètre définissant à quel moment le succès de la réception d'un message doit être vérifié
3.39
Sync_Mark
valeur courante du temps local enregistrée au moment de l'impulsion de synchronisation des trames,
Frame_Synchronisation
3.40
matrice du système
formulaire contenant tous les messages de tous les nœuds du réseau, organisés comme des composants, et
consistant en des fenêtres de temps organisées en cycles de base (lignes de la matrice) et en colonnes de
transmission (colonnes de la matrice)
NOTE La matrice du système spécifie la corrélation entre les messages et les fenêtres de temps (type et marque
temporelle). Le premier cycle de base de la matrice du système commence par le numéro de cycle Cycle_Count 0.
3.41
intervalle de temps
durée comprise entre la fin d'un cycle de base et le début du cycle de base suivant, lorsque le début de ce
cycle de base suivant est synchronisé avec un événement
3.42
marque temporelle
marque, dans une entité de synchronisation des trames, définissant un instant du Cycle_Time (en unités de
temps du réseau, NTU) où une certaine action est attendue ou prévue
3.43
horloge maîtresse
entité de synchronisation des trames (FSE) qui envoie le message de référence
3.44
fenêtre de temps
durée affectée à une colonne de transmission spécifique dans la matrice du système
3.45
colonne de transmission
colonne de la matrice du système dont les éléments sont en corrélation avec une fenêtre de temps donnée
qui est répétée dans chaque cycle de base
NOTE Les lignes de transmission sont les cycles de base de la matrice du système.
3.46
rapport d'unité de temps
TUR
rapport entre la longueur d'une unité de temps du réseau (NTU) et la longueur de l'unité de temps
fondamentale spécifique à l'entité de synchronisation des trames (FSE) (par exemple la période de
l'oscillateur local) utilisé pour la synchronisation horloge
NOTE En principe, le TUR ne correspond pas à un nombre entier. La vue nodale d'une NTU est implémentée par
utilisation de la valeur du TUR.
3.47
Tx_Count
compteur qui est réinitialisé à chaque début d'un cycle de la matrice, c'est-à-dire après identification du
message de référence correspondant avec Cycle_Count égal à zéro
3.48
Tx_Enable
période pendant laquelle la transmission d'un message peut être lancée
3.49
Tx_Overflow
indicateur d'état positionné lorsqu'il se produit un nombre de Tx_Trigger supérieur au nombre attendu défini
par Expected_Tx_Trigger
3.50
Tx_Ref_Trigger
paramètre Tx_Trigger spécial ne concernant que le déclenchement de messages de référence
3.51
Tx_Trigger
paramètre définissant à quel moment un certain message sera transmis; il est composé d'une marque
temporelle, de la position à l'intérieur de la colonne de transmission par rapport au premier envoi
(Cycle_Offset) et de la cadence de répétition (Repeat_Factor) à l'intérieur de cette colonne de transmission,
ainsi que d'une référence à un objet message pour lequel le paramètre Tx_Trigger est valide
NOTE Le paramètre Tx_Trigger contient également des informations sur le type de fenêtre (exclusive, d'arbitrage,
fusionnée).
3.52
Tx_Underflow
indicateur d'état positionné lorsqu'il se produit un nombre de Tx_Trigger inférieur au nombre attendu défini par
Expected_Tx_Trigger
3.53
Watch_Trigger
marque temporelle permettant de vérifier si le temps écoulé depuis le dernier message de référence valide a
été trop long
4 Termes abrégés
CAN gestionnaire de réseau de communication (Controller Area Network)
FSE entité de synchronisation des trames (Frame Synchronisation Entity)
LLC contrôle de liaison logique (Logical Link Control)
LSB bit le moins significatif (Least Significant Bit)
6 © ISO 2004 – Tous droits réservés
MAC contrôle d'accès au support (Medium Access Control)
MSB bit le plus significatif (Most Significant Bit)
SOF début de trame (Start of Frame)
5 Concepts fondamentaux du CAN à déclenchement temporel des communications
5.1 Conventions générales
Pour les besoins de la présente partie de l'ISO 11898, les conventions suivantes sont applicables.
Le chien de garde de l'application est régulièrement servi par le paramètre Host_Alive_Sign.
Les conflits de fenêtre de temps d'arbitrage sont résolus par arbitrage selon l'identifiant du CAN, et un
nœud CAN ne peut pas lancer une transmission si le bus n'est pas inactif. Plusieurs nœuds CAN du réseau
peuvent commencer une transmission à l'intérieur de la fenêtre Tx_Enable d'une fenêtre de temps d'arbitrage.
La retransmission automatique immédiate est désactivée. Exception: fusion de fenêtres de temps.
Les éléments du cycle de base sont plusieurs fenêtres de temps consécutives. Le nombre et la longueur des
différentes fenêtres de temps sont spécifiés hors ligne et sont identiques pour l'ensemble du réseau. Chaque
cycle de base de la matrice du système est composé de la même séquence de fenêtres de temps et
commence par la fenêtre de temps contenant le message de référence.
Cycle_Time est tronqué aux 16 bits les plus significatifs de la différence entre le temps local d'une FSE et
son paramètre Ref_Mark; Cycle_Time = 16 bits les plus significatifs de (Local_Time – Ref_Mark).
Cycle_Count commence la numérotation à zéro.
Cycle_Offset fait partie d'un paramètre Tx_Trigger ou Rx_Trigger.
Gravité de l'erreur: pas d'erreur (S0), avertissement (S1), erreur (S2) et erreur grave (S3).
Expected_Tx_Trigger: lorsque Tx_Count atteint Expected_Tx_Trigger, tous les paramètres Tx_Trigger
suivants de cette FSE dans le cycle courant de la matrice sont désactivés.
La FSE gère la transmission ou la réception des messages de référence temporelle et fournit une interface
d'état et de contrôle à la couche d'application.
Les fenêtres de temps libres sont réservées pour des extensions futures du réseau.
Global_Sync_Mark (niveau 2 uniquement) est enregistré au moment de l'impulsion de synchronisation des
trames, Frame_Synchronisation. Cette valeur contient la partie entière de 16 bits ainsi que la partie décimale
de la somme (temps local + décalage local).
Init_Watch_Trigger a la valeur de 2 –1, c'est-à-dire le maximum du temps de cycle.
Le temps local est généré avec une largeur de 16 bits au niveau 1 et d'au moins 19 bits au niveau 2. À
l'exception des 16 MSB au niveau 2, tous les autres bits donnent la partie décimale d'une NTU. La procédure
d'incrémentation du temps local doit garantir que la partie non décimale est incrémentée une fois par
équivalent local de la NTU.
EXEMPLE Si la partie décimale utilise 3 bits, le temps local est incrémenté 8 fois au niveau 2, chaque incrément
correspondant à l'équivalent local de NTU/8.
À l'intérieur d'une fenêtre de temps d'arbitrage fusionnée, la retransmission de trames qui ont perdu
l'arbitrage ou qui ont été perturbées par une erreur est activée.
La NTU est une constante de l'ensemble du réseau:
au niveau 1, la NTU correspond à la durée nominale d'un bit CAN;
au niveau 2, la NTU est une fraction de la seconde physique.
La vue nodale du temps global correspond à la partie entière de la somme du temps local du nœud et de
son décalage local, Local_Offset. La partie décimale est exclusivement réservée à la synchronisation horloge.
En conséquence, la vue nodale du temps global est l'image locale du temps global en NTU (locales). Il doit
être possible de fournir la vue nodale du temps global sous la forme d'une valeur monotonique continue à
l'application.
Ref_Mark: à chaque achèvement correct du message de référence, le paramètre Sync_Mark courant devient
Ref_Mark.
Rx_Trigger: l'information nécessaire à un Rx_Trigger est constituée par une marque temporelle (instant
après lequel il est prévu que la réception du message correspondant sera achevée), par la position à
l'intérieur de la colonne de transmission par rapport à la première réception (Cycle_Offset) et par la cadence
de répétition (Repeat_Factor) à l'intérieur de cette colonne de transmission ainsi que, bien entendu, par une
référence à un objet message pour lequel le paramètre Rx_Trigger est valide. Plusieurs Rx_Trigger peuvent
être spécifiés pour le même message. Les paramètres Rx_Trigger sont réservés à des messages envoyés
dans des fenêtres de temps exclusives.
Fenêtre de temps: cette fenêtre peut être de trois types, fenêtre de temps exclusive, fenêtre de temps
d'arbitrage et fenêtre de temps libre.
Le TUR (niveau 2 uniquement) est utilisé pour la synchronisation horloge.
Tx_Count: chaque fois qu'un Tx_Trigger devient actif, Tx_Count est incrémenté. Tx_Count n'est pas
incrémenté au-delà de Expected_Tx_Trigger.
Tx_Enable s'ouvre avec Tx_Trigger et se ferme après un nombre défini à l'avance de durées nominales du
bit CAN qui est spécifié par la configuration du système.
Watch_Trigger: la valeur de ce paramètre dépend du mode de fonctionnement (synchronisation
événementielle ou déclenchement temporel) du CAN à déclenchement temporel.
5.2 Principe général du protocole
5.2.1 Matrice du système — Cycle de la matrice
Dans un système à déclenchement temporel des communications, tous les messages de tous les nœuds du
réseau peuvent être organisés comme des composants d'une matrice du système. La matrice du système
spécifie la corrélation entre les messages et les fenêtres de temps au cours desquelles ils doivent être
envoyés. Dans le CAN à déclenchement temporel des communications, la matrice du système doit être
organisée en cycles de base (lignes de la matrice) et en colonnes de transmission (colonnes de la matrice).
Le nombre des cycles de base de la matrice du système doit être une puissance de deux (2), sa valeur
minimale est un (1). Chaque cycle de base commence par un message possédant des caractéristiques
particulières, le message de référence (voir Figure 1).
8 © ISO 2004 – Tous droits réservés
Figure 1 — Cycle de base d'un CAN à déclenchement temporel des communications
À l'intérieur d'un cycle de base, un message peut être affecté à plus d'une fenêtre de temps, c'est-à-dire qu'un
message spécifique peut appartenir à plus d'une colonne de transmission. Le cycle de tous les cycles de
base de la matrice du système doit être le cycle de la matrice. À l'intérieur d'un cycle de la matrice,
Cycle_Count doit compter le nombre des cycles de base. Le comptage doit commencer à zéro et doit se
terminer à Cycle_Count_Max. La valeur courante de Cycle_Count doit être transmise par l'horloge maîtresse
dans le message de référence. Elle doit, en particulier, être incrémentée de façon cyclique à chaque cycle de
base par l'horloge maîtresse. Toute FSE recevant un message de référence valide doit utiliser le numéro de
cycle transmis dans ce message de référence. Le nombre de cycles de base dans un cycle de la matrice
(Cycle_Count_Max+1) doit être un nombre entier puissance de deux (2).
Une colonne du cycle de la matrice est appelée colonne de transmission. À l'intérieur d'une colonne de
transmission, un message spécifique peut être transmis périodiquement avec une période qui est une
puissance de deux (2) sans être supérieure au nombre des lignes de la matrice du système. L'unité de la
période est «lignes de la matrice du système». Le numéro (valeur de Cycle_Count) du cycle de base dans
lequel ce message spécifique est transmis pour la première fois est appelé Cycle_Offset, la période est
appelée Repeat_Factor (facteur de répétition). Un message spécifique peut appartenir à plus d'une colonne
de transmission et peut être transmis dans plus d'une fenêtre de temps d'une colonne de transmission.
5.2.2 Fenêtres de temps
Chaque message doit être transmis dans une fenêtre de temps particulière. À l'intérieur d'une fenêtre de
temps, la transmission d'un message ne peut être lancée que pendant la fenêtre Tx_Enable (voir 7.2.2), c'est-
à-dire que le bit de début de trame (SOF) du message doit se situer dans la fenêtre Tx_Enable.
Dans un CAN à déclenchement temporel des communications, trois types différents de fenêtres de temps
doivent être prévus:
des fenêtres de temps exclusives;
des fenêtres de temps libres;
des fenêtres de temps d'arbitrage.
Un cycle de base peut consister en des fenêtres de temps de longueur et de type différents. Toutes les
fenêtres de temps d'une colonne de transmission doivent avoir la même longueur mais peuvent être de types
différents (voir la Figure 2 qui représente une matrice de système dont le paramètre Cycle_Count_Max = 3).
Figure 2 — Matrice du système
Des fenêtres de temps exclusives sont affectées à un message spécifique transmis périodiquement sans
concurrence pour l'accès au bus CAN. Une seule FSE du réseau peut commencer une transmission dans une
fenêtre de temps exclusive. Des fenêtres de temps d'arbitrage sont affectées à des messages qui partagent la
même fenêtre de temps. À l'intérieur des fenêtres de temps d'arbitrage, les conflits d'accès au bus sont
résolus par arbitrage du CAN en fonction de l'identifiant. Plusieurs FSE du réseau peuvent lancer une
transmission dans la fenêtre de temps d'arbitrage. En cas de perte de l'arbitrage, la retransmission
automatique doit être désactivée (exception: les fenêtres d'arbitrage fusionnées). Les fenêtres de temps
d'arbitrage consécutives peuvent être fusionnées en une seule fenêtre. Les trames qui ont perdu l'arbitrage ou
qui ont été perturbées par une erreur peuvent être retransmises à l'intérieur de la fenêtre de temps d'arbitrage
fusionnée. Les fenêtres de temps libres sont réservées pour des extensions futures du réseau.
NOTE Pour plus de détails concernant les fenêtres Tx_Enable, voir 7.2.2.
5.2.3 Début d'un cycle de base à synchronisation événementielle
Dans un système à déclenchement temporel des communications qui n'est pas synchronisé par les
événements, les messages de référence doivent être transmis périodiquement dans des créneaux de temps
équidistants. Le CAN à déclenchement temporel des communications doit avoir la possibilité de synchroniser
les cycles de base sur un événement spécifique dans les nœuds de l'horloge maîtresse. Lorsque la
communication doit être synchronisée, le transfert cyclique de messages doit être interrompu après la fin d'un
cycle de base et un intervalle de temps peut apparaître entre la fin du dernier cycle de base périodique et le
début du cycle de base suivant, à synchronisation événementielle. L'intervalle de temps doit être annoncé par
10 © ISO 2004 – Tous droits réservés
l'horloge maîtresse courante dans le message de référence du dernier cycle de base. L'intervalle de temps se
termine dès que l'horloge maîtresse courante ou l'une des horloges maîtresses potentielles envoie un
message de référence pour lancer le cycle de base suivant du cycle de la matrice. Cela est représenté à la
Figure 3.
NOTE Le démarrage à synchronisation événementielle d'un cycle de base peut être utilisé pour synchroniser les
cycles de transmission de deux ou plus bus CAN à déclenchement temporel.
Figure 3 — Cycle de base à synchronisation événementielle
5.3 Message de référence
5.3.1 Description
Toute communication périodique à déclenchement temporel sur le bus CAN doit avoir pour base le message
de référence. Un message de référence doit être une trame de données caractérisée par un identifiant CAN
spécifique et il est reçu et accepté par toutes les FSE à l'exception de l'horloge maîtresse (expéditeur du
message de référence). Pour le niveau 1, le code de longueur des données doit être au moins un (1); pour le
niveau 2, la longueur des données doit être au moins de quatre (4); sinon, le message ne doit pas être
accepté comme message de référence. Tous les bits de l'identifiant, à l'exception des trois (3) LSB,
caractérisent le message comme étant un message de référence. Les 3 derniers bits doivent spécifier la
priorité d'un nombre d'horloges maîtresses potentielles allant jusqu'à 8.
Au niveau 1 comme au niveau 2, le message de référence doit contenir le numéro du cycle de base courant
(Cycle_Count) et le bit d'état, Next_is_Gap, qui annonce si le cycle suivant commencera par la transmission à
synchronisation événementielle du message de référence. Au niveau 2, le message de référence doit en
outre contenir le paramètre Master_Ref_Mark (mesuré en temps global) et le bit d'état, Disc_Bit, qui annonce
s'il existe une discontinuité dans le temps global. L'horloge maîtresse doit transmettre le message de
référence, généralement dans des créneaux de temps équidistants ou, facultativement, synchronisés sur un
événement spécifique. Si le message de référence est perturbé par une erreur, il doit être possible de le
retransmettre immédiatement. Noter que, si la retransmission est désactivée, il se peut qu'il n'y ait plus de
communication sur le bus. En cas de retransmission, le paramètre Master_Ref_Mark transmis doit être mis à
jour. Le message de référence doit généralement être envoyé périodiquement, mais il est permis d'arrêter la
transmission périodique (bit Next_is_Gap) et de déclencher par synchronisation événementielle le début du
cycle de base suivant au moyen de l'horloge maîtresse courante ou de l'une des horloges maîtresses
potentielles.
L'horloge maîtresse doit être la FSE qui transmet les messages de référence. L'horloge maîtresse doit être
autorisée à transmettre d'autres messages. Si l'horloge maîtresse courante est défectueuse, sa fonction doit
être reprise par une autre FSE appartenant aux horloges maîtresses potentielles. Chaque horloge maîtresse
potentielle doit utiliser un identifiant CAN spécifique et distinct lorsqu'elle transmet un message de référence,
cet identifiant étant défini en fonction de sa priorité en tant qu'horloge maîtresse. Chacun des identifiants CAN
spécifiques doit être reconnu par toutes les FSE du réseau comme un identifiant de message de référence.
Les FSE qui ne sont ni l'horloge maîtresse ni une horloge maîtresse potentielle sont des FSE qui reçoivent les
indications de temps.
Le message de référence doit avoir des formats différents pour le niveau 1 et le niveau 2 (voir les Figures 4
et 5). Dans les deux cas, le message de référence peut être prolongé par d'autres données jusqu'à une
somme de huit octets de données CAN. Les bits réservés doivent être transmis sous la forme de 0 logiques et
doivent être ignorés par les destinataires.
5.3.2 Niveau 1
Le message de référence correspondant au niveau 1 doit consister en au moins un octet de données. Le
premier octet contient le bit Next_is_Gap et le paramètre Cycle_Count. Le MSB (bit numéro sept) est transmis
en premier. Une FSE du CAN à déclenchement temporel des communications peut arriver à traiter des
valeurs de Cycle_Count allant jusqu'à 63 (six bits). Il n'est pas indispensable qu'une FSE de CAN à
déclenchement temporel des communications assure une telle prise en charge.
NOTE Il est possible d'utiliser sans incompatibilité des FSE prenant en charge un nombre maximum différent de
cycles de base, Cycle_Count_Max, dans un réseau CAN à déclenchement temporel des communications. Il est
cependant nécessaire de s'assurer que toutes les horloges maîtresses potentielles de ce réseau prennent en charge la
valeur maximale qui est utilisée au sein du réseau par l'une quelconque des FSE.
7 6 5 4 3 2 1 0
Next_is_Gap Réservé Facultatif: Facultatif: Facultatif: Facultatif: Facultatif: Facultatif:
Cycle_Count Cycle_Count Cycle_Count Cycle_Count Cycle_Count Cycle_Count
(5) (4) (3) (2) (1) (0)
Figure 4 — Format du message de référence — Niveau 1
5.3.3 Niveau 2
Le message de référence correspondant au niveau 2 doit consister en au moins quatre octets de données
(voir Figure 5). Le premier octet doit contenir le bit Next_is_Gap et le paramètre Cycle_Count. Le MSB (bit
numéro sept) de chaque octet doit être transmis en premier.
Le deuxième octet doit contenir le bit de discontinuité (Disc_Bit, voir 6.6) et les bits de résolution de l'unité de
temps du réseau (NTU_Res). Ces derniers correspondent aux parties décimales de Master_Ref_Mark. Au
niveau 2, trois bits au minimum doivent être pris en charge pour NTU_Res; facultativement, une FSE peut
prendre en charge des bits supplémentaires jusqu'à une résolution de 7 bits. Les bits qui ne sont pas pris en
charge doivent être envoyés sous la forme d'un 0 logique.
Le troisième octet doit contenir l'octet inférieur de Master_Ref_Mark (MRM) et le quatrième octet doit contenir
l'octet supérieur de Master_Ref_Mark (MRM).
12 © ISO 2004 – Tous droits réservés
Premier octet
7 6 5 4 3 2 1 0
Next_is_Gap Réservé Facultatif: Facultatif: Facultatif: Facultatif: Facultatif: Facultatif:
Cycle_Count Cycle_Count Cycle_Count Cycle_Count Cycle_Count Cycle_Count
(5) (4) (3) (2) (1) (0)
Deuxième octet
7 6 5 4 3 2 1 0
NTU_Res NTU_Res NTU_Res Facultatif: Facultatif: Facultatif: Facultatif: Disc_Bit
(6) (5) (4) NTU_Res NTU_Res NTU_Res NTU_Res
(3) (2) (1) (0)
Troisième octet
7 6 5 4 3 2 1 0
MRM MRM MRM MRM MRM MRM MRM MRM
(7) (6) (5) (4) (3) (2) (1) (0)
Quatrième octet
7 6 5 4 3 2 1 0
MRM MRM MRM MRM MRM MRM MRM MRM
(15) (14) (13) (12) (11) (10) (9) (8)
Figure 5 — Format du message de référence — Niveau 2
6 Caractéristiques de temporisation et de synchronisation
6.1 Niveau 1 et niveau 2
Il existe deux niveaux possibles dans un CAN à déclenchement temporel des communications, le niveau 1 et
le niveau 2. Le niveau 1 assure uniquement un fonctionnement avec déclenchement temporel utilisant
Cycle_Time. Le niveau 2 doit en outre apporter une meilleure qualité de la synchronisation, un temps global et
la synchronisation horloge externe. Aux deux niveaux, toutes les caractéristiques de synchronisation doivent
s'appuyer sur une base de temps locale, le temps local. En principe, toutes les FSE du réseau doivent
mesurer leur temps local en utilisant la NTU. La vue nodale de la NTU diffère généralement de façon
marginale de la vue réseau; cela tient à de légères différences dans les oscillateurs locaux (horloges
système). Au niveau 2, la procédure de synchronisation doit garantir que ces vues locales d'une NTU dans
différentes FSE sont très proches les unes des autres (voir 6.4). Au niveau 1, la NTU est la durée nominale du
bit CAN; au niveau 2, la NTU est une fraction de la seconde physique.
Il est possible de mélanger des FSE de niveau 1 et de niveau 2 au sein d'un réseau CAN à déclenchement
temporel des communications si la NTU du niveau 2 est égale à la NTU du niveau 1 (durée nominale du bit
CAN). Dans un réseau mixte de ce type, toutes les horloges maîtresses potentielles doivent cependant être
de niveau 2.
6.2 Génération du temps local
Dans chaque FSE, le temps local doit être implanté par un compteur incrémentiel cyclique. Au niveau 1, le
compteur doit contenir 16 bits, avec comptage en unités d'une NTU (au niveau 1, la durée nominale du bit
CAN). Au niveau 2, le compteur doit contenir au moins 19 bits parmi lesquels, à l'exception des 16 MSB, tous
n
les bits donnent les parties décimales d'une NTU, c'est-à-dire que le com
...
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...