ISO 11992-2:2014

INTERNATIONAL ISO
STANDARD 11992-2
Third edition
2014-05-01
Road vehicles — Interchange of digital
information on electrical connections
between towing and towed vehicles —
Part 2:
Application layer for brakes and
running gear
Véhicules routiers — Échange d’informations numériques sur
les connexions électriques entre véhicules tracteurs et véhicules
tractés —
Partie 2: Couche d’application pour les équipements de freinage et les
organes de roulement
Reference number
©
ISO 2014
© ISO 2014
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 2014 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 4
5 General Specifications . 4
6 Application layer . 5
6.1 Protocol Data Unit (PDU) specification . 5
6.2 Parameter group number (PGN) . 7
6.3 Address assignment. 7
6.4 Message routing . 9
6.5 Parameters .10
6.6 Messages .57
7 Conformance tests .72
7.1 General .72
7.2 Conformance tests for commercial vehicles .72
7.3 Conformance tests for towed vehicles .73
Annex A (normative) Geometric data .75
Annex B (informative) Message flow .79
Bibliography .83
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
The committee responsible for this document is ISO/TC 22, Road vehicles, Subcommittee SC 3, Electrical
and electronic equipment.
This third edition cancels and replaces the second edition (ISO 11992-2:2003), which has been technically
revised. It also replaces ISO 11992-2:2003/Amd 1:2007.
ISO 11992 consists of the following parts, under the general title Road vehicles — Interchange of digital
information on electrical connections between towing and towed vehicles:
— Part 1: Physical and data-link layers
— Part 2: Application layer for brakes and running gear
— Part 3: Application layer for equipment other than brakes and running gear
— Part 4: Diagnostic communication
iv © ISO 2014 – All rights reserved

Introduction
This part of ISO 11992 has been established in order to define the data interchange between a commercial
vehicle and its towed vehicle(s), including the communication between towed vehicles, using a Controller
Area Network (CAN) serial data link as specified in ISO 11992-1 for control and status data related to
electronically controlled braking and running gear applications.
It is subject to additions which will become necessary in order to keep pace with experience and technical
advances. Care has been taken to ensure that these additions can be introduced in a compatible way,
and care will have to be taken in the future so that such additions remain compatible with the previous
versions. In particular, it can become necessary to standardize new parameters and parameter groups.
ISO members can request that such new parameters and parameter groups are to be included in the
future editions of ISO 11992.
INTERNATIONAL STANDARD ISO 11992-2:2014(E)
Road vehicles — Interchange of digital information
on electrical connections between towing and towed
vehicles —
Part 2:
Application layer for brakes and running gear
1 Scope
This part of ISO 11992 specifies the parameters and messages for electronically controlled braking
systems, including anti-lock braking systems (ABS) and vehicle dynamics control systems (VDC), as well
as for running gear equipment (i.e. systems for steering, suspension, and tyres), to ensure that the data
communication interchange of information between road vehicles with a maximum authorized total
mass greater than 3 500 kg and their towed vehicles, including the communication between (several)
towed vehicles, on a dedicated network. It does not include any other communication on that network
that is not related to the communication between those vehicles.
2 Normative references
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 7638 (all parts), Road vehicles — Connectors for the electrical connection of towing and towed vehicles
ISO 11898-1, Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling
ISO 11992-1, Road vehicles — Interchange of digital information on electrical connections between towing
and towed vehicles — Part 1: Physical and data-link layers
ISO 11992-4, Road vehicles — Interchange of digital information on electrical connections between towing
and towed vehicles — Part 4: Diagnostic communication
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 11898-1, ISO 11992-1, and the
following apply.
3.1
anti-lock braking system
ABS
control function which automatically modulates the pressure producing the braking forces at the wheels
to limit the degree of wheel slip, or a system that provides an anti-lock braking function
3.2
anti-spin regulation
ASR
control function which automatically modulates the engine torque or the pressure producing the braking
forces at the wheels to limit the degree of wheel spin, or a system that provides an anti-spin control
3.3
center-axle trailer
towed vehicle equipped with a rigid towing device, and in which the axle(s) is (are) positioned close to
the centre of gravity of the vehicle
3.4
commercial vehicle
motor vehicle which, on account of its design and appointments, is used mainly for conveying goods and
which can also tow a trailer
3.5
converter dolly
dolly unit that couples to a semi-trailer with a fifth-wheel coupling and thereby “converts” the semi-
trailer to a full trailer
3.6
electronic braking system
EBS
braking system in which control is generated and processed as an electrical signal in the control
transmission
3.7
electronic control unit
ECU
electronic item consisting of a combination of basic parts, subassemblies, and assemblies packaged
together as a physically independent entity
3.8
full trailer
towed vehicle equipped with a towing device which can move vertically (in relation to the trailer), and
in which the axle(s) is (are) positioned less close to the centre of gravity of the vehicle
3.9
gateway
unit connecting different networks or parts of one network and performing any necessary protocol
translation
3.10
link trailer
towed vehicle with a fifth-wheel coupling, designed for towing a semi-trailer
3.11
network segment
part of a network that is within the domain of a single link layer
3.12
node
device capable of sending or receiving data whose identification will be unambiguous for authentication
purposes
3.13
running rear equipment
RGE
equipment of a vehicle, including steering, suspension, and tyres
3.14
roll-over prevention/protection
ROP
control function to prevent roll-over situations of a vehicle
Note 1 to entry: ROP is part of a VDC (3.20) function.
2 © ISO 2014 – All rights reserved

Note 2 to entry: In UNECE Regulation No. 13, roll-over prevention is referred to as “roll-over control”.
3.15
semi-trailer
trailer which is designed to be coupled to a semi-trailer towing vehicle and to impose a substantial part
of its total weight on the towing vehicle
3.16
towed vehicle
non-power-driven road vehicle which, on account of its design and appointments, is used to transport
persons or goods and is intended to be towed by a motor vehicle
3.17
towing full trailer
towed vehicle equipped with a towing device which can move vertically (in relation to the trailer), and
in which the axle(s) is (are) positioned less close to the centre of gravity of the vehicle that is capable of
towing another vehicle
3.18
towing semi-trailer
trailer which is designed to be coupled to a semi-trailer towing vehicle and to impose a substantial part
of its total weight on the towing vehicle that is capable of towing another vehicle
3.19
towing vehicle
motor vehicle or non-power-driven vehicle which tows a succeeding vehicle
3.20
vehicle dynamic control
VDC
control function as part of the braking system that reacts to stabilize the vehicle during dynamic
manoeuvres
Note 1 to entry: VDC has the possible sub-functions ROP (3.14) and YC (3.21).
3.21
yaw control
YC
control function to reduce an unwanted lateral movement of a vehicle
Note 1 to entry: Yaw control is part of a VDC (3.20) function.
Note 2 to entry: In UNECE Regulation No. 13, YC is referred to as “directional control”.
4 Symbols and abbreviated terms
CAN Controller Area Network
CAN-ID CAN identifier
DA destination address
DLC data length code
DP data page
EDP extended data page
GE group extension
LSB least significant byte (or bit)
MSB most significant byte (or bit)
P priority
PDU Protocol Data Unit
PF PDU format
PGN parameter group number
PS PDU specific
SA source address
TOS type of service
UTC Universal Time Coordinate
5 General Specifications
The data link shall be in accordance with ISO 11898-1. The physical layer shall be in accordance with
ISO 11992-1.
Appropriate PDUs are specified to structure the communication between the towing and towed vehicles’
interface(s). These PDUs shall be transmitted between the electronic devices (nodes) at the towing
vehicle and each towed vehicle, as defined in the following sections.
Each node at a vehicle shall provide logical separation between the network segments and any in-vehicle
networks and act as a gateway to forward the messages, as specified in the following sections.
Any combination of new and old towing and towed vehicles is allowed. Multiple towed vehicles can be
connected in any combination. The network shall be capable of addressing any towed vehicle, including
dollies. The truck operator can disconnect and connect towed vehicles at any time and any order, and the
network shall adjust and respond accordingly.
4 © ISO 2014 – All rights reserved

6 Application layer
6.1 Protocol Data Unit (PDU) specification
6.1.1 General
The application layer provides a string of information that is assembled as a PDU. The PDU provides a
framework for organizing the information sent by means of CAN data frames.
All transmitted CAN data frames shall use the extended data frame format with a 29-bit CAN-ID as
defined in ISO 11898-1. The PDU framework for the normal and diagnostic communications between the
commercial vehicles and towed vehicles is the same as defined in Reference [1] and is specified in 6.1.2.
Diagnostic communication between the towed vehicles shall use the subnet addressing PDU format as
specified in 6.1.3.
6.1.2 PDU format for normal communication and diagnostic communication (PDU1 and PDU2)
The PDU1 and PDU2 shall consist of the following fields as shown in Figure 1:
— a 29-bit CAN-ID with the subfields priority (P), extended data page (EDP), data page (DP), PDU
format (PF), PDU specific (PS) [which can be a destination address (DA) or a group extension (GE)],
and source address (SA);
— a 64-bit data field.
Figure 1 — PDU1 and PDU2 structure
Depending on the contents of the subfields, the PDUs are classified as PDU1 or PDU2 frames as given in
the following definitions.
6.1.3 PDU format for subnet addressing communication (PDU3)
The PDU3 shall consist of the following fields as shown in Figure 2:
— a 29-bit CAN-ID with the subfields priority (P), extended data page (EDP), data page (DP), type of
service (TOS), destination address (DA) and source address (SA);
— a 64-bit data field.
Figure 2 — PDU3 structure
The fields P, EDP, and DP shall be used as given in the following definitions. All other fields shall be used
as defined in ISO 11992-4.
6.1.4 Priority (P)
This 3-bit subfield shall be used to optimize the PDU frame latency for transmission onto the bus only
and shall have no other specific meaning. It shall not be used for message validation on the receiver side
and should be globally masked off by the receiver (ignored). The priority of any PDU can be set from
highest, 0 (000 ), to lowest, 7 (111 ), and will use the following default values.
10 2 10 2
— The default for all control-oriented PDUs shall be 3 (011 ).
10 2
— The default of all other informational PDUs shall be 6 (110 ).
10 2
— The default for diagnostic PDUs shall be 7 (111 ).
10 2
6.1.5 Extended data page (EDP)
This 1-bit subfield shall be used in conjunction with the DP subfield to select an auxiliary range of PGNs
or to select subnet addressing diagnostic messages. The definition of a PGN is given in 6.2. The definition
of CAN frames for subnet addressing diagnostic messages is given in 6.6.
6.1.6 Data page (DP)
This 1-bit subfield shall be used in conjunction with the EDP subfield to select an auxiliary range of PGNs
or to select subnet addressing diagnostic messages. The definition of a PGN is given in 6.2. The definition
of CAN frames for subnet addressing diagnostic messages is given in 6.6.
6.1.7 PDU format (PF)
This 8-bit subfield shall determine the PDU format and the transmission method as specified in Table 1.
— If the value of the PDU format field is below 240, then the PDU format is of type PDU1 and the PDU-
specific field contains a destination address.
— If the value of the PDU format field is 240 to 255, then the PDU format is of type PDU2 and the PDU-
specific field contains a group extension.
Table 1 — PDU definition
PF value PDU format PS Transmission method
0 to 239 PDU1 DA This PDU 1 format shall be used for messages to be sent directly to either a
specific or a global destination.
240 to 255 PDU2 GE This PDU 2 format shall only be used to communicate global (broadcast)
messages.
6.1.8 PDU specific (PS)
6.1.8.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) (see Table 1).
6.1.8.2 Destination address (DA)
The DA shall contain the specific address of the towing or towed vehicle to which the PDU is being sent.
If the global destination address (255 = FF ) is sent, all nodes shall process the PDU.
10 16
6 © ISO 2014 – All rights reserved

6.1.8.3 Group extension (GE)
The GE in conjunction with the four least significant bits of the PF subfield shall be used as part of the
specific PGN.
6.1.9 Source address (SA)
This 8-bit subfield shall provide the source address (SA) of the node that transmits the PDU. Therefore
the SA subfield ensures that the CAN-ID is unique on all network segments.
6.1.10 Data field
All CAN data frames shall use a data field length of 8 byte, i.e. DLC = 8. If less than 8 byte are required by
the defined PGN, all non-used bits shall be transmitted with all bits set to “1”.
6.2 Parameter group number (PGN)
This 24-bit number shall be used in all cases where a group of parameters assembled in the PDU1 or
PDU2 data field needs to be identified. A PGN is built from the CAN-ID subfields EDP, DP, PF, and PS
as specified in Figure 3 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 (LSB) of the PGN shall always be set to zero (0).
Figure 3 — PGN subfield definition
NOTE To reduce the effort of exchanging PDUs between the ISO 11992-2 communication and any in-vehicle
network, the PGNs within this International Standard are harmonized with those used in SAE J1939.
EXAMPLE For a message with CAN-ID 18FEC920 (PDU2 format), the subfields are P = 110 , EDP = 0 ,
16 2 2
DP = 0 , PF = FE , PS = C9 , and SA = 20 . The corresponding PGN is 00FEC9 (65225 ).
2 16 16 16 16 10
6.3 Address assignment
6.3.1 Address usage
A road train consists of one truck (commercial vehicle) and one or more trailer(s) (towed vehicles).
Dollies within the road train shall be treated as additional towed vehicles (see Figure 4).
The commercial vehicle is the towing vehicle of towed vehicle #1; towed vehicle #1 is the towing vehicle
of towed vehicle #2; and so on.
Key
1 truck/commercial vehicle (position #0) 3 converter dolly/towed vehicle position #2
2 trailer/towed vehicle position #1 4 trailer/towed vehicle position #3
Figure 4 — Example of a possible road train configuration
For the towing vehicle/towed vehicle communication, each node shall use only the addresses given in
Table 2 as SA and DA for all messages.
Table 2 — Commercial vehicle/towed vehicle addresses
Name Address Predecessor Successor
commercial vehicle (#0) 32 / 20 n/a towed vehicle #1
10 16
towed vehicle #1 200 / C8 commercial vehicle (#0) towed vehicle #2
10 16
towed vehicle #2 192 / C0 towed vehicle #1 towed vehicle #3
10 16
towed vehicle #3 184 / B8 towed vehicle #2 towed vehicle #4
10 16
towed vehicle #4 176 / B0 towed vehicle #3 towed vehicle #5
10 16
towed vehicle #5 168 / A8 towed vehicle #4 undefined
10 16
global destination address 255 / FF undefined undefined
10 16
The global destination address shall only be used by the commercial vehicle to broadcast information to
all the towed vehicles simultaneously.
6.3.2 Address assignment procedure
The address of the commercial vehicle is fixed. The respective address of a towed vehicle corresponds
to its position within the road train and shall be (re)assigned each time
— a communication starts or
— the towed vehicle has been connected to the road train.
The dynamic address assignment shall be handled by the respective towing/towed vehicle’s node
and concerns the determination of the individual position within the road train. It is based on the
transmission of the general initialization message (see 6.6.4.1) by the respective predecessor within the
road train.
Within a road train, the address assignment procedure shall be initiated by the commercial vehicle,
using its default address for the general initialization message. A powered-up towed vehicle’s node shall
use the address of towed vehicle #1 as the default address for transmitting the available information
until the general initialization message has been received from the towing vehicle and a valid address
can be assigned.
8 © ISO 2014 – All rights reserved

Each towed vehicle’s node shall use the general initialization message received at the towing vehicle’s
network interface to determine its own address. It shall use the successor’s address of that message’s SA
as its own address. This requires that a towed vehicle’s node shall be capable of
— identifying its predecessor by the SA of the general initialization message,
— assigning its own address based on the predecessors address, and
— identifying the potential receiver(s) by the destination address and by the message type.
An assigned address shall be valid as long as the towed vehicle is powered and no message from the
predecessor with a different SA is received. If a different SA is received, the assignment procedure shall
be restarted.
To provide the address assignment for itself and for possible successors, a node shall be capable
of continuously sending the general initialization message with its dynamically assigned own SA as
illustrated in Figure 5.
This addressing method allows the towed vehicle’s node to communicate and to identify its presence
to its predecessor immediately after power-up. This means that several towed vehicles can use the
same address until the address assignment procedure is completed. Continuous sending of the general
initialization message is necessary to allow immediate towed vehicle address assignment at any time a
towed vehicle should be connected.
Figure 5 — Address assignment procedure
6.4 Message routing
If a vehicle has no provision for a successor, the message routing function is not required by the vehicle’s
node.
To allow communication between the towing and towed vehicles, a node shall be capable of
— receiving messages from its predecessor and successor within the road train,
— identifying receiver(s) by the destination address (PDU 1 type messages) or the PDU format (PDU 2
type messages),
— routing all applicable messages from its predecessor(s) to its successor(s) within the road train
by sending them with the unchanged SA and DA to its successor within a maximal delay time of
t = 13 ms, and
d
— routing all applicable messages from its successor(s) to its predecessor(s) within the road train
by sending them with the unchanged SA and DA to its predecessor within a maximal delay time of
t = 13 ms.
d
A towed vehicle node shall not route messages to its successor or predecessor within the road train
— if the SA of a message received from its predecessor corresponds to a road train position closer or
equal to its own from the commercial vehicle or
— if the SA of a message received from its successor corresponds to a road train position more distant
or equal to its own from the commercial vehicle.
EXAMPLE Figure 6 shows some examples of the message flow between vehicles.
Figure 6 — Example of the message flow between vehicles
6.5 Parameters
6.5.1 Generic data ranges
Each defined parameter shall comply with one of the defined parameter types.
— Table 3 specifies the ranges used to determine the validity of the transmitted signals.
— Table 4 specifies the ranges used to denote the status of a discrete parameter.
10 © ISO 2014 – All rights reserved

— Table 5 specifies the ranges used to denote the status of a control mode command.
The values in the range “error indicator” provide a means for a module to immediately indicate that valid
parameter data are not currently available, owing to some type of error in the sensor, subsystem, or
module. Additional information about the failure can be obtained using the diagnostic communication.
The values in the range “not available” provide a means for a module to transmit a parameter that is not
available or not supported in that module. This value does not replace the “error indicator”.
The values in the range “not requested” provide a means for a device to transmit a command message
and identify those parameters where no response is expected from the receiving device.
The values in the range of “special function” are reserved for the definition of parameter-specific
functionalities.
For some parameters, non-generic definitions are given in the following sections. These are not defined
here. Examples are encoded table values, where each value is assigned to one specific meaning.
After power-on, a node shall internally set the “availability bits” of the received parameters as “not
available” and operate with the default values until valid data are received. When transmitting,
undefined bytes shall be sent as 255 (FF ) and undefined bits shall be sent as “1”.
10 16
If a failure of a function or device prevents the transmission of valid data for a parameter, the error
indicator, as specified in Table 3, Table 4, or Table 5, shall be used in place of that parameter data. However,
if the measured or calculated data has yielded a value that is valid yet exceeds the defined parameter
range, the error indicator shall not be used. The data shall be transmitted using the appropriate minimum
or maximum parameter value.
A 2-byte (16-bit) parameter shall be sent (least significant byte first, most significant byte second).
Table 3 — Transmitted signal ranges
Range name 1 byte 2 byte
valid signal 0 to 250 0 to 64255
10 10 10 10
0 to FA 0 to FAFF
16 16 16 16
reserved for future indicators 251 to 253 64256 to 65023
10 10 10 10
FB to FD FB00 to FDFF
16 16 16 16
error indicator 254 65024 to 65279
10 10 10
FE FE00 to FEFF
16 16 16
not available or 255 65280 to 65535
10 10 10
not requested
FF FF00 to FFFF
16 16 16
Table 4 — Transmitted values for discrete parameters (measured)
Range name Transmitted value
disabled (off, passive, insufficient) 00
enabled (on, active, sufficient) 01
error indicator 10
not available or not installed 11
Table 5 — Transmitted values for control requests (status)
Range name Transmitted value
command to disable function (turn off, etc.) 00
command to enable function (turn on, etc.) 01
special function (parameter specific) 10
don’t care/take no action (leave function as it is) 11
6.5.2 General parameter specification
A description of each parameter is given in 6.5.3, 6.5.4, and 6.5.5. The description includes data length,
data type, resolution, and range for reference.
The type of data shall also be identified for each parameter. Data can be either status or measured.
— Status data specifies a command requesting an action to be performed by the receiving node.
Examples of status-type data are “service brake demand value” and “ride height request”.
— Measured data conveys the current value of a parameter as measured or observed by the
transmitting node to determine the condition of the defined parameter. Examples of measured-
type data are “wheel-based vehicle speed” and “lift axle 1 position”. Note that a measured-type
parameter can indicate the condition of the defined parameter, even if no measurement has been
taken. For example, the measured-type parameter can indicate that a solenoid has been activated,
even if no measurement has been taken to ensure the solenoid accomplished its function.
For each parameter, the attributes given in Table 6 shall apply.
Table 6 — Attribute definition
Attribute Definition
data length required number of bits/bytes of the parameter
resolution weight of a bit in physical unit
offset value of the binary value 0 (zero) in physical unit
data range physical range of data that the parameter is able to hold
operating range physical range of data that can be used
type type of data as specified in this section
The PGN reference attribute is informative. The PGN parameters are specified in 6.6.
6.5.3 System independent parameters
6.5.3.1 Tyre/wheel identification
This parameter shall indicate the identification number of the tyre or wheel. The identification number
shall specify the tyre or wheel position on each axle (bit 1 to bit 4) and the number of axles starting from
the front of the respective towed vehicle (bit 5 to bit 8) (see Figure 7).
The tyre/wheel identification shall only be used as complementary information in conjunction with all
the tyre, wheel, or wheel-end related information in the PGN’s message and shall be ignored if those
parameters are not supported. The identification number “0” shall be used if the position of the tyre,
wheel, wheel-end, or axle cannot be identified. Table 7 specifies the parameter description.
12 © ISO 2014 – All rights reserved

Table 7 — Specification of the parameter “tyre/wheel identification”
Attribute Value
data length 1 byte
resolution encoded table value
bit 1 to bit 4
0000  – wheel position undefined
0001 to 1111 – wheel position 1 to 15
2 2
bit 5 to bit 8
0000  – axle position undefined
0001 to 1111 – axle position 1 to 15
2 2
type measured
Assignment rules
— The tyre/wheel identification shall be assigned sequentially from the vehicle’s centre line, starting
from “9” incrementing on the right side and from “7” decrementing on the left side, in the normal
direction of travel. “8” is used for the one wheel on the centre line as illustrated in Figure 7.
— It is assumed that each wheel rim has one and only one tyre.
— In situations when the number of wheels on each wheel-end cannot be identified, or the wheel-end
alone is to be identified, the parameters shall be identified using the default wheel position 7 left
and 9 right in the normal direction of travel.
— In cases when the wheel definition is shared, within the same PGN, with another parameter or
parameters, the wheel-end can be specified as a wheel position 1 to 7 on the left-hand side or 9 to 15
on the right-hand side, as required by the other parameter or parameters.
— In situations when more than 15 axles are present on the vehicle, the first 15 axles shall be identified
using this procedure; the additional axles shall then be identified with the axle identification “0”
together with the respective wheel identification.
NOTE Due to the parameter definition, there is an ambiguity between “parameter not supported” (255 )
and wheel = 15 and axle = 15 . As the identification number serves only as complementary information for
10 10
other parameters, the value of 255 identifies only a valid position if those parameters are supported.
Figure 7 — Tyre/wheel and axle position
6.5.3.2 Seconds
This parameter shall indicate the component “seconds” of the current time of day. This should be reported
as the seconds of the current time at UTC; however, it can be reported as the component seconds of the
current time at a local time zone. The local hour/minute offset parameters (6.5.3.8 and 6.5.3.9) are used
to indicate if the time of day is the current UTC time or a local time zone time. Table 8 specifies the
parameter description.
Table 8 — Specification of the parameter “seconds”
Attribute Value
data length 1 byte
resolution 0,25 s/bit
offset 0 s
data range 0 s to 62,5 s
operating range 0 s to 59,75 s
type measured
6.5.3.3 Minutes
This parameter shall indicate the component “minutes” of the current time of day. This should be reported
as the minutes of the current time at UTC; however, it can be reported as the component minutes of the
current time at a local time zone. The local hour/minute offset parameters (6.5.3.8 and 6.5.3.9) are used
14 © ISO 2014 – All rights reserved

to indicate if the time of day is the current UTC time or a local time zone time. Table 9 specifies the
parameter description.
Table 9 — Specification of the parameter “minutes”
Attribute Value
data length 1 byte
resolution 1 min/bit
offset 0 min
data range 0 min to 250 min
operating range 0 min to 59 min
type measured
6.5.3.4 Hours
This parameter shall indicate the component “hour” of the current time of day. This should be reported
as the hours of the current time at UTC; however, it can be reported as the component hours of the
current time at a local time zone. The local hour/minute offset parameters (6.5.3.8 and 6.5.3.9) are used
to indicate if the time of day is the current UTC time or a local time zone time. Table 10 specifies the
parameter description.
Table 10 — Specification of the parameter “hours”
Attribute Value
data length 1 byte
resolution 1 h/bit
offset 0 h
data range 0 h to 250 h
operating range 0 h to 23 h
type measured
6.5.3.5 Day
This parameter shall indicate the component “day” of the current time of day. This should be reported as
the day of the current time at UTC; however, it can be reported as the component day of the current time
at a local time zone. The local hour/minute offset parameters (6.5.3.8 and 6.5.3.9) are used to indicate
if the time of day is the current UTC time or a local time zone time. Table 11 specifies the parameter
description.
Table 11 — Specification of the parameter “day”
Attribute Value
data length 1 byte
resolution 0,25 day/bit
offset 0 day
data range 0 day to 62,50 days
operating range 0,25 day to 31,75 days
type measured
NOTE A value of 0 for the day is null. The values 1, 2, 3, and 4 indicate the first day of a month; the values 5, 6,
7, and 8 indicate the second day of the month, etc.
6.5.3.6 Month
This parameter shall indicate the component “month” of the current time of day. This should be reported
as the month of the current time at UTC; however, it can be reported as the component month of the
current time at a local time zone. The local hour/minute offset parameters (6.5.3.8 and 6.5.3.9) are used
to indicate if the time of day is the current UTC time or a local time zone time. Table 12 specifies the
parameter description.
Table 12 — Specification of the parameter “month”
Attribute Value
data length 1 byte
resolution 1 mo/bit
offset 0 mo
data range 0 mo to 250 mo
operating range 1 mo to 12 mo
type measured
NOTE A value of 0 is null. A value of 1 identifies January, 2 identifies February, etc.
6.5.3.7 Year
This parameter shall indicate the component “year” of the current time of day. This should be reported
as the year of the current time at UTC; however, it can be reported as the component year of the current
time at a local time zone. The local hour/minute offset parameters (6.5.3.8, 6.5.3.9) are used to indicate
if the time of day is the current UTC time or a local time zone time. Table 13 specifies the parameter
description.
Table 13 — Specification of the parameter “year”
Attribute Value
data length 1 byte
resolution 1 y/bit
offset 1985 y
data range 1985 y to 2235 y
operating range 1985 y to 2235 y
type measured
NOTE A value of 0 identifies year 1985, 1 identifies year 1986, etc.
6.5.3.8 Local minute offset
This parameter shall indicate the component “minute” of the offset between the UTC time and date and
a local time zone time and date and is defined as the number of minutes to add to the UTC time and date
to convert it into the time and date of a local time zone.
— The local offset is a positive value for time zones east of the prime meridian to the international date
line.
— The local offset is a negative value for time zones west of the prime meridian to the international
date line.
The local minute offset is only applicable when the time and date parameters are reported as UTC time
and date. Table 14 specifies the parameter description.
16 © ISO 2014 – All rights reserved

Table 14 — Specification of the parameter “local minute offset”
Attribute Value
data length 1 byte
resolution 1 min/bit
offset −125 min
data range −125 min to 125 min
operating range −59 min to 59 min
type measured
6.5.3.9 Local hour offset
This parameter shall indicate the component “hour” of the offset between the UTC time and date and a
local time zone time and date and is defined as the number of hours to add to the UTC time and date to
convert it into the time and date of a local time zone.
— The local offset is a positive value for time zones east of the prime meridian to the international date
line.
— The local offset is a negative value for time zones west of the prime meridian to the international
date line.
The local hour offset is only applicable when the time and date parameters are reported as UTC time and
date. Table 15 specifies the parameter description.
Table 15 — Specification of the parameter “local hour offset”
Attribute Value
data length 1 byte
resolution 1 h/bit
offset −125 h
data range −125 h to 125 h
operating range −23 h to 23 h
type measured
6.5.3.10 Identification data index
This parameter shall be used as an index to an array of identification data as defined by the parameter
“identification data content” (6.5.3.11) and shall not be used without that context. Table 16 specifies the
parameter description.
Table 16 — Specification of the parameter “identification data index”
Attribute Value
data length 1 byte
resolution 1/bit
offset 0
data range 0 to 250
operating range 0 to 250
type measured
6.5.3.11 Identification data content
This parameter shall be interpreted as an array of identification data that is indexed by the parameter
“identification data index” (6.5.3.10). Table 17 and Table 18 specify the parameter description.
Table 17 — Specification of the parameter “identification data”
Attribute Value
data length 1 byte
resolution 1/bit
offset 0
data range 0 to 250
operating range 0 to 250
type measured
Table 18 — Specification of the parameter “identification data content”
Index Attribute Value
0 to 16 parameter VIN
content vehicle identification number
resolution ASCII
data range ASCII
17 to 250 reserved by document
6.5.4 Parameters for braking systems
6.5.4.1 Park brake demand relative pressure
This parameter shall command the requested brake pressure for the parking brake as a percentage of
the maximum pressure. Table 19 specifies the parameter description.
Table 19 — Specification of the parameter “park brake demand relative pressure”
Attribute Value
data length 1 byte
resolution 0,4 %/bit
offset 0 %
data range 0 % to 100 %
operating range 0 % to 100 %
type status
6.5.4.2 Retarder demand relative torque
This parameter shall command the requested torque of the retarder on the towed vehicle(s) as a
percentage of the absolute peak torque of the retarder. Table 20 specifies the parameter description.
18 © ISO 2014 – All rights reserved

Table 20 — Specification of the parameter “retarder demand relative torque”
Attribute Value
data length 1 byte
resolution 1 %/bit
offset −125 %
data range −125 % to 125 %
operating range −125 % to 0 %
type status
In the definition of power train speed/torque, the retarder torque reaction is a deceleration specified
by
...