ISO 16844-4:2015
(Main)Road vehicles — Tachograph systems — Part 4: CAN interface
Road vehicles — Tachograph systems — Part 4: CAN interface
ISO 16844-4:2015 specifies the controller area network (CAN) interface for the interchange of digital information between a road vehicle's tachograph system and vehicle units, and within the tachograph system itself. It specifies parameters of, and requirements for, the application of physical and data link layers of the electrical connection used in the electronic systems.
Véhicules routiers — Systèmes tachygraphes — Partie 4: Interface CAN
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 16844-4
Second edition
2015-01-15
Road vehicles — Tachograph systems —
Part 4:
CAN interface
Véhicules routiers — Systèmes tachygraphes —
Partie 4: Interface CAN
Reference number
ISO 16844-4:2015(E)
©
ISO 2015
---------------------- Page: 1 ----------------------
ISO 16844-4:2015(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2015
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
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 2015 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 16844-4:2015(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative reference . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 1
5 Physical layer application requirements . 2
5.1 General . 2
5.2 Bit timing requirements . 3
5.2.1 General. 3
5.2.2 CAN bit timing requirements for 250 kbit/s . 3
5.2.3 CAN bit timing requirements for 500 kbit/s . 4
6 Data link layer application requirements . 4
6.1 Message frame format . 4
6.1.1 General. 4
6.1.2 Priority (P) bits . 5
6.1.3 Extended data page (EDP) bit . 5
6.1.4 Data page (DP) bit . . 5
6.1.5 PDU format (PF) field . 5
6.1.6 PDU specific (PS) field . 5
6.1.7 Source address (SA) field. 5
6.1.8 Data field . 6
6.2 PDU specification . 6
6.2.1 Parameter group number (PGN) . 6
6.2.2 PDU format . 6
6.3 Message types . 6
6.3.1 General. 6
6.3.2 RQST — Request . 7
6.3.3 ACKM — Acknowledgment message. 8
7 Transport protocol . 8
7.1 General . 8
7.2 BAM — Broadcast announce message . 9
7.3 TP.DT — Transport protocol — Data transfer . 9
8 Application layer .10
8.1 General .10
8.2 TD — Time/Date .10
8.3 VI — Vehicle identification .11
8.4 VDHR — High resolution vehicle distance .11
8.5 SERV — Service information .12
8.6 RESET — Reset .12
8.7 TCO1 — Tachograph .13
8.8 DI — Driver’s identification .14
8.9 TDA — Time/Date adjust .14
8.10 EEC1 — Electronic engine controller 1 .15
8.11 CL — Cab illumination message .16
8.12 DRTD1 — Driver 1 driving rest times .16
8.13 DRTD2 — Driver 2 driving rest times .17
9 Addresses .18
Bibliography .19
© ISO 2015 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO 16844-4:2015(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
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. Details of any
patent rights identified during the development of the document will be in the Introduction and/or on
the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical Barriers
to Trade (TBT), see the following URL: Foreword — Supplementary information.
This second edition cancels and replaces the first edition (ISO 16844-4:2004), which has been
technically revised.
The committee responsible for this document is ISO/TC 22, Road vehicles, Subcommittee SC 3, Electrical
and electronic equipment.
ISO 16844 consists of the following parts, under the general title Road vehicles — Tachograph systems:
— Part 1: Electrical connectors
— Part 2: Electrical interface with recording unit
— Part 3: Motion sensor interface
— Part 4: CAN interface
— Part 5: Secured CAN interface
— Part 6: Diagnostics
— Part 7: Parameters
iv © ISO 2015 – All rights reserved
---------------------- Page: 4 ----------------------
ISO 16844-4:2015(E)
Introduction
This International Standard supports and facilitates the communication between electronic control units
[1]
and a tachograph. The tachograph is based upon the European Council Regulation (EC) No 561/2006
[2]
and (EEC) No 3821/85 as last amended.
The digital tachograph concept is based upon an RU storing data, related to the activities of the various
drivers driving the vehicle, on which it is installed.
During the normal operational status of the RU, data stored in its memory are accessible to different
entities (drivers, authorities, workshops, transport companies) in different ways (displayed on a screen,
printed by a printing device, downloaded to an external device). Access to stored data is controlled by
smart card inserted in the tachograph.
In order to prevent manipulation of the tachograph system, the speed signal sender (motion sensor) is
provided with an encrypted data link.
A typical tachograph system is shown in Figure 1.
Key
1 positive supply
2 battery minus
3 speed signal, real time
4 data signal in/out
Figure 1 — Typical tachograph system
© ISO 2015 – All rights reserved v
---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO 16844-4:2015(E)
Road vehicles — Tachograph systems —
Part 4:
CAN interface
1 Scope
This part of ISO 16844 specifies the controller area network (CAN) interface for the interchange of digital
information between a road vehicle’s tachograph system and vehicle units, and within the tachograph
system itself. It specifies parameters of, and requirements for, the application of physical and data link
layers of the electrical connection used in the electronic systems.
2 Normative reference
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. 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 16844-7, Road vehicles — Tachograph systems — Part 7: Parameters
3 Terms and definitions
For the purpose of this document, the following terms and definitions apply.
3.1
recording unit
RU
part of the tachograph system which acquires and stores data concerning the vehicle and its driver(s)
and their activities
Note 1 to entry: A recording unit is also referenced as a vehicle unit in other standards, both are synonyms.
3.2
visual instrument
speedometer and display(s) for odometer and trip meter data
4 Symbols and abbreviated terms
ACK positive acknowledge
BAM broadcast announce message
CAN controller area network
DA destination address
DP data page
ECU electronic control unit
© ISO 2015 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO 16844-4:2015(E)
EDP extended data page
EOL end-of-line
LSB least significant bit/byte
MSB most significant bit/byte
NACK negative acknowledge
P priority
PDU protocol data unit
PF PDU format
PG parameter group
PGN parameter group number
Phase_Seg1 phase buffer segment 1
Phase_Seg2 phase buffer segment 2
Prop_Seg propagation time segment
PS PDU specific
RU recording unit
SA source address
Sync_Seg synchronization segment
TP.DT transport protocol data transfer
t bit time
s
t time quanta
q
t timing segment 1
SEG1
t timing segment 2
SEG2
t synchronization jump width
SJW
VIN vehicle identification number
5 Physical layer application requirements
5.1 General
[4] [5]
The physical layer shall meet the requirements of SAE J1939-11 for 250 kbit/s and SAE J1939-14 for
500 kbit/s unless otherwise specified in this part of ISO 16844.
2 © ISO 2015 – All rights reserved
---------------------- Page: 7 ----------------------
ISO 16844-4:2015(E)
5.2 Bit timing requirements
5.2.1 General
The following values of CAN bit timing parameters specified in ISO 11898-1 shall be used for the settings
of the tachograph ECUs as given in Figure 2.
t = 1t
Sync_Seg q
t = t + t
SEG1 Prop_Seg Phase_Seg1
t = t
SEG2 Phase_Seg2
a
t
BIT
Sync_seg Prop_seg Phase_Seg 1 Phase_Seg 2
ISO 11898 terms:
t t t
ISO 16844 terms:
Sync_Seg SEG 1 SEG2
Key
1 sample point
a
Nominal bit time.
Figure 2 — Partition of bit time
5.2.2 CAN bit timing requirements for 250 kbit/s
For a physical layer configured to 250 kbit/s, the parameter values given in Table 1 shall apply.
Table 1 — CAN bit timing parameter values for 250 kbit/s, single data sampling mode
Parameter Timing setting
Min Nominal Max
t 3 980 ns 4 000 ns 4 020 ns
B
t — — 400 ns
q
t t = t – 1t – t t = t – 1t – t t = t – 1t – t
SEG1 SEG1 B q SEG2 SEG1 B q SEG2 SEG1 B q SEG2
The CAN bit timing values shall also comply with the following conditions:
— nominal bit rate: 250 kbit/s ±0,5 %;
— sample point: between 80 % and 88 % of nominal bit time of single data sampling mode.
Values for the bit timing shall be according to Table 2, which is based on time quanta, t .
q
© ISO 2015 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO 16844-4:2015(E)
Table 2 — CAN bit timing parameter values for 250 kbit/s for a given time quanta, t
q
Parameter
t t t
q SJW SEG2
200 ns 600 ns 600 ns
250 ns 500 ns 750 ns
334 ns 668 ns 668 ns
400 ns 800 ns 800 ns
5.2.3 CAN bit timing requirements for 500 kbit/s
For a physical layer configured to 500 kbit/s, the parameter values given in Table 3 shall apply.
Table 3 — CAN bit timing parameter values for 500 kbit/s, single data sampling mode
Parameter Timing setting
Min Nominal Max
t 1 980 ns 2 000 ns 2 020 ns
B
t — — 200 ns
q
t t = t – 1t – t t = t – 1t – t t = t – 1t – t
SEG1 SEG1 B q SEG2 SEG1 B q SEG2 SEG1 B q SEG2
The CAN bit timing values shall also comply with the following conditions:
— nominal bit rate: 500 kbit/s ±1 %;
— clock tolerance: ±0,05 %;
— sample point: between 80 % and 88 % of nominal bit time of single data sampling mode.
Values for the bit timing shall be according to Table 4, which is based on time quanta, t .
q
Table 4 — CAN bit timing parameter values for 500 kbit/s for a given time quanta, t
q
Parameter values
t t t
q SJW SEG2
100 ns 300 ns 400 ns
125 ns 375 ns 375 ns
167 ns 334 ns 334 ns
200 ns 400 ns 400 ns
6 Data link layer application requirements
6.1 Message frame format
6.1.1 General
For the data link layer, the application layer provides a string of information that is assimilated into a PDU.
The PDU provides a framework for organizing the information, which shall be sent in the CAN data frame.
The 29-bit identifier shall be in accordance with ISO 11898-1.
The PDU shall consist of seven fields in addition to the specific CAN fields specified in Figure 3.
4 © ISO 2015 – All rights reserved
---------------------- Page: 9 ----------------------
ISO 16844-4:2015(E)
The PDU fields shall contain P, EDP, DP, PF, PS, which may be a DA or a GE, SA, and data field.
Figure 3 — Usage of 29 bit CAN identifier and data field
NOTE For compatibility with other definitions (e.g. ISO 11898-1, J1939), the bit positions of the identifier field
start with index 0, and the bit/byte positions within the data field start with index 1.
6.1.2 Priority (P) bits
This 3-bit subfield shall be used to optimize PDU message latency for transmission onto the bus only
and shall have no other specific meaning. It shall not be used for message validation on receiver side and
should be globally masked off by the receiver (ignored). The priority of any PDU may be set from highest,
0 (000 ), to lowest, 7 (111 ) and will use the default values as given in the PGN specifications. Other
10 2 10 2
values may be specified by the system integrator (vehicle manufacturer).
6.1.3 Extended data page (EDP) bit
This 1-bit subfield shall be used in conjunction with the DP subfield to select a range of PGNs. The
definition of a PGN is given in 6.2.
6.1.4 Data page (DP) bit
This 1-bit subfield shall be used in conjunction with the EDP subfield to select a range of PGNs. The
definition of a PGN is given in 6.2.
6.1.5 PDU format (PF) field
This 8-bit subfield shall determine the PDU format and the transmission method as specified in 6.2.
6.1.6 PDU specific (PS) field
6.1.6.1 General
This 8-bit subfield shall depend on the PDU format. For a PDU1 format, the PDU specific (PS) subfield is
a destination address (DA); for a PDU2 format, the PS subfield is a group extension (GE).
6.1.6.2 Destination address (DA) field
The DA addresses the ECU intended to receive and act upon the message. In case of the global destination
address (255 /FF ), all nodes shall process the PDU.
10 16
6.1.6.3 Group extension (GE) field
The GE field extends the four least significant bits of the PF field, and provides 4 096 PGNs. It indicates
that the PS field is a group extension when the four most significant bits of PF field are set.
6.1.7 Source address (SA) field
The SA field shall be 8-bit long. There shall be only one device on the network with a given SA, i.e. the SA
assures that the CAN identifiers are unique.
© ISO 2015 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO 16844-4:2015(E)
6.1.8 Data field
A single CAN frame shall provide a maximum of eight data bytes within the data field. If not specified in
the message definition, all eight bytes shall be used, even if fewer are required. This provides means to
easily add parameters while remaining compatible with previous revisions, which only specified part
of the data field.
All unused data fields shall be set to the value “not available” [all bits set to one (1)].
6.2 PDU specification
6.2.1 Parameter group number (PGN)
This 24-bit number shall be used in all cases where a group of parameters (PG) assembled in the PDU
data field need to be identified. A PGN is built from the CAN-ID subfields EDP, DP, PF, and PS as specified
in Figure 4 and is used to identify or label a group of parameters. It is independent of the remaining
fields of the CAN-ID.
The upper bits, 18 to 23, are reserved and shall always be set to zero (0). For a PDU1 message, i.e. if the
PS field is a DA, the least significant byte (PS) of the PGN shall always be set to zero (0).
Figure 4 — Contents of the PGN
6.2.2 PDU format
The PDU format is either PDU1 or PDU2 and specifies the transmission method and the content of the PS field.
— If the value of the PDU format field is in the range of 0 to 239, the PDU format is of type PDU1 and
the PS field contains a destination address. The PDU1 format is used for PGs to be sent to either a
specific destination of broadcasted to global destination.
— If the value of the PDU format field is in the range of 240 to 255, then PDU format is of type PDU2 and
the PDU-specific field contains a group extension. The PDU2 format is used to communicate global PGs.
6.3 Message types
6.3.1 General
The RU shall respond to a PGN request:
a) If the request is directly addressed to the RU with addresses as specified in Clause 9.
1) If the RU supports the requested PGN, then the RU shall transmit the requested PGN.
6 © ISO 2015 – All rights reserved
---------------------- Page: 11 ----------------------
ISO 16844-4:2015(E)
2) If the RU doesn’t support the requested PGN, then the RU shall respond with the NACK.
b) If the request is globally addressed with the address as specified in Clause 9.
1) If the RU supports the requested PGN, then the RU shall transmit the requested PGN.
2) If the RU doesn’t support the requested PGN, then the RU shall not respond.
If the RU submits a response, a NACK or broadcast of the requested PGN, it shall transmit it within
200 ms after reception of the PGN request. The requesting device shall not issue another request within
1 250 ms from the first request in case of a response from the RU.
For each message, the attribute definition given in Table 5 shall apply.
Table 5 — Message attribute definition
Attribute Definition
Transmission repetition time The nominal time and tolerance between two subsequently transmitted
messages.
Data length The number of bytes of the message.
Extended data page The value of parameter EDP as specified in 6.1.3.
Data page The value of parameter DP as specified in 6.1.4.
PDU format The value of parameter PF as specified in 6.1.5.
PDU specific The value of parameter PS as specified in 6.1.6.
Default priority The recommended value of parameter P as specified in 6.1.2.
PGN The value of parameter PGN as specified in 6.2.
Byte pos The byte position of the parameter in the PDU data field, starting with 1.
Bit pos The bit position of the parameter within the data byte, starting with 1.
Parameter The name of the parameter as specified in ISO 16844-7.
Remark Attribute used for comments, if required.
6.3.2 RQST — Request
The request message, identified by the PGN, shall be used to request information from a specific device
or globally. Only information that is not broadcast periodically shall be requested. Table 6 specifies the
PG attributes. Table 7 specifies the PG content.
Table 6 — PGN 59904 — RQST attribute specification
Attribute Value
Transmission repetition time sent if sending of a PGN is required
Data length 3 byte
Extended data page 0
Data page 0
PDU format 234 (PDU1)
PDU specific DA (global or specific)
Default priority 6
PGN 59904 /00EA00
10 16
© ISO 2015 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO 16844-4:2015(E)
Table 7 — PGN 59904 — RQST parameter specification
Byte pos Bit pos Parameter Remark
1 to 3 PGN being requested —
(byte 1 is LSB, byte 3 is MSB)
NOTE The data field of this message consists of 3 byte only as a deviation to the requirements given in 6.1.8.
6.3.3 ACKM — Acknowledgment message
Acknowledgement shall provide a handshake between transmitting and receiving devices. Table 8
specifies the PG attributes. Table 9 specifies the PG content.
Table 8 — PGN 59392 — ACKM attribute specification
Attribute Value
Transmission repetition time on request
Data length 8 byte
Extended data page 0
Data page 0
PDU format 232 (PDU1)
10
PDU specific DA = 255 (Global)
10
Default priority 6
PGN 59392 /00E800
10 16
Table 9 — PGN 59392 — ACKM parameter specification
Byte pos Bit pos Parameter Remark
1 Control byte See Table 10
2 Group function value Not used
(send 255 )
10
3 to 5 Reserved by document —
6 to 8 PGN of requested information/PGN that required the —
acknowledgement
(byte 6 is LSB, byte 8 is MSB)
Table 10 — Control byte specification
Control byte Interpretation Use
0 ACK — When the local time adjustment was successful (see 8.9).
— When the trip distance was reset (see 8.6).
1 NACK — When a non-supported PGN was requested with a specific request.
— When the local time adjustment was not successful (see 8.9).
7 Transport protocol
7.1 General
The transport protocol is invoked when PGs containing more than 8 byte are transmitted and shall
[6]
be implemented according to SAE J1939-21. The first frame to be transmitted shall be the BAM as
8 © ISO 2015 – All rights reserved
---------------------- Page: 13 ----------------------
ISO 16844-4:2015(E)
defined in 7.2, followed by required number of TP.DT containing the segmented data as defined in 7.3.
The time between messages (interframe space) shall be in the range of 50 ms to 200 ms.
For each message, the attribute definition given in Table 5 shall apply.
7.2 BAM — Broadcast announce message
The BAM message parameters shall be used as defined in Table 11 and Table 12.
Table 11 — PGN 60416 — BAM attribute specification
Attribute Value
Transmission repetition time per PG to be transmitted
Data length 8 byte
Extended data page 0
Data page 0
PDU format 236 (PDU1)
PDU specific 255 (DA, Global)
Default priority 6
PGN 60416 /00EC00
10 16
Table 12 — PGN 60416 — BAM parameter specification
Byte pos Bit pos Parameter Remark
1 Control byte, fixed value 32 —
10
2 to 3 Total message size in number of bytes 9 to 1 785
4 Total number of packets 2 to 255
5 Reserved by document —
6 to 8 PGN of packed message —
(byte 6 is LSB, byte 8 is MSB)
7.3 TP.DT — Transport protocol — Data transfer
TP.DT shall be used to transmit the segmented data of a PG. The TP.DT message is an individual packet
of a multipacket transfer. Table 13 specifies the PG attributes. Table 14 specifies the PG content.
Table 13 — PGN 60160 — TP.DT attribute specification
Attribute Value
Transmission repetition time per PG to be transmitted
Data length 8 byte
Extended data page 0
Data page 0
PDU format 235 (PDU1)
PDU specific DA = 255 (Global)
10
Default priority 6
PGN 60160 /00EB00
10 16
© ISO 2015 – All rights reserved 9
---------------------- Page: 14 ----------------------
ISO 16844-4:2015(E)
Table 14 — PGN 60160 — TP.DT parameter specification
Byte pos Bit pos Parameter Remark
1 Sequence number 1 to 255
2 to 8 Packed data —
Packed data format:
— The packed data bytes shall be sent with MSB first.
— If the
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.