ISO 13185-2:2015

INTERNATIONAL ISO
STANDARD 13185-2
First edition
2015-04-01
Intelligent transport systems —
Vehicle interface for provisioning and
support of ITS services —
Part 2:
Unified gateway protocol (UGP)
requirements and specification for
vehicle ITS station gateway (V-ITS-
SG) interface
Systèmes intelligents de transport — Interface véhicule pour la
fourniture et le support de services ITS —
Partie 2: Exigences de protocole et spécification pour l’interface
passerelle de la station ITS du véhicule
Reference number
©
ISO 2015
© 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

Contents Page
Foreword .vi
Introduction .vii
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, symbols, and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Abbreviated terms . 2
4 Conventions . 3
5 Document overview. 4
6 UGP application layer services. 6
6.1 General . 6
6.2 Service primitives . 6
6.3 Application layer service primitives — Confirmed service . 7
6.4 Format description of service primitives . 8
6.4.1 General definition . 8
6.4.2 Service request and service indication primitives. 8
6.4.3 Service response and service confirm primitives . 9
6.4.4 Service request-confirm and service response-confirm primitives .10
6.5 UGP service call with global reply message handling .10
6.6 UGP service call with scheduled-based reply message handling .11
6.7 UGP service data unit specification .12
6.7.1 Mandatory parameters .12
7 UGP application layer protocol in ASN.1 document interface .13
7.1 General definition .13
7.2 Common message data and structure.13
7.3 ASN.1 model .14
8 Unified gateway protocol (UGP) clusters .15
8.1 Overview .15
8.2 UGP service clusters and associated services .15
9 UGP service cluster 1 — Global services .16
9.1 GlobalPositiveReply .16
9.2 GlobalNegativeReply .16
9.3 StopService .17
9.3.1 Service description .17
9.3.2 Message ‘StopServiceCall’ .17
9.3.3 Positive reply .17
9.3.4 Error handling .17
9.3.5 Example .17
9.4 Reset .18
9.4.1 Service description .18
9.4.2 Message ‘ResetCall’ .18
9.4.3 Positive reply .18
9.4.4 Error handling .18
9.4.5 Example .18
10 UGP service cluster 2 — Authentication .19
10.1 Authentication .19
10.1.1 Service description .19
10.1.2 Message ‘AuthenticationCall’ .19
10.1.3 Message ‘AuthenticationReply’ .19
10.1.4 Error handling .20
10.1.5 Example .20
11 UGP service cluster 3 — Supported data .21
11.1 GetSupportedData .21
11.1.1 Service description .21
11.1.2 Message ‘GetSupportedDataCall’ .21
11.1.3 Message ‘GetSupportedDataReply’ .22
11.1.4 Error handling .23
11.1.5 Example without ECU data .23
11.1.6 Example with ECU data .24
11.1.7 ECU filtered example .25
11.1.8 Negative access type and data parameter property filtered example .26
12 UGP service cluster 4 — Data parameter access .26
12.1 GetValue .26
12.1.1 Service description .26
12.1.2 Message ‘GetValueCall’ . . .26
12.1.3 Message ‘GetValueReply’ .27
12.1.4 Error handling .28
12.1.5 Single get data parameter list example .28
12.1.6 Asynchronous conditioned example .29
12.1.7 Monitor example .30
12.1.8 Structure example ‘vehicle info’ .31
12.2 SetValue .32
12.2.1 Service description .32
12.2.2 Message ‘SetValueCall’ .32
12.2.3 Positive reply .33
12.2.4 Error handling .33
12.2.5 Example .33
12.3 ControlValue .34
12.3.1 Service description .34
12.3.2 Message ‘ControlValueCall’ .34
12.3.3 Message ‘ControlValueReply’ .34
12.3.4 Error handling .35
12.3.5 Example 1 .35
12.3.6 Example 2 .38
13 UGP service cluster 5 — Diagnostic trouble code information access .39
13.1 GetDtcInfo .39
13.1.1 Service description .39
13.1.2 Message ‘GetDtcInfoCall’ .39
13.1.3 Message ‘GetDtcInfoReply’ .40
13.1.4 Error handling .41
13.1.5 Examples .41
13.2 ClearDtcInfo .42
13.2.1 Service description .42
13.2.2 Message ‘ClearDtcInfoCall’ .42
13.2.3 Positive reply .42
13.2.4 Error handling .42
13.2.5 Example .42
14 UGP service cluster 6 — In-vehicle network access .43
14.1 EnablePassThru .43
14.1.1 Service description .43
14.1.2 Message ‘EnablePassThruCall’ .43
14.1.3 Positive reply .44
14.1.4 Error handling .44
14.1.5 Example .44
15 UGP service cluster 7 — Maintenance .45
15.1 ListFile .45
iv © ISO 2015 – All rights reserved

15.1.1 Service description .45
15.1.2 Message ‘ListFileCall’ .45
15.1.3 Message ‘ListFileReply’ .46
15.1.4 Error handling .46
15.1.5 Example .46
15.2 ManageFile .47
15.2.1 Service description .47
15.2.2 Message ‘ManageFileCall’ .47
15.2.3 Message ‘ManageFileReply’ .48
15.2.4 Error handling .48
15.2.5 Example download . . .48
15.2.6 Example upload .49
15.2.7 Example delete .50
Annex A (normative) Vehicle Interface Data Format definition (VIDF) .51
Annex B (normative) Unified gateway protocol ASN.1 definition .70
Bibliography .78
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 204, Intelligent transport systems.
ISO 13185 consists of the following parts, under the general title Intelligent transport systems (ITS) —
Vehicle interface for provisioning and support of ITS services:
— Part 1: General information and use case definition
— Part 2: Unified gateway protocol (UGP) requirements and specification for vehicle ITS station gateway
(V-ITS-SG) interface
The following parts are under preparation:
— Part 3: Unified gateway protocol (UGP) server and client API specification
— Part 4: Unified gateway protocol (UGP) conformance test specification
vi © ISO 2015 – All rights reserved

Introduction
This part of ISO 13185 has been established to define the requirements of a common software interface
to a vehicle gateway to easily exchange vehicle information data amongst nomadic and/or mobile device,
vehicle gateway, and the vehicle’s Electronic Control Units (ECUs).
Applications supporting service provision use via nomadic and mobile devices need vehicle information
data through an in-vehicle interface access method, as well as the harmonization of existing standards
to support a single vehicle data access solution.
This document defines an ASN.1-based protocol between the nomadic and/or mobile device (ND) and
the UGP Server (implemented in the V-ITS-SG) in the vehicle.
To achieve this, it is based on the Open Systems Interconnection (OSI) Basic Reference Model specified in
ISO/IEC 7498-1 and ISO/IEC 10731, which structures communication systems into seven layers.
This part of ISO 13185 can be used by vehicle manufacturers for future vehicle design to support the
design of vehicle gateways to interface with NDs.
The ND applications need vehicle information data through an in-vehicle interface access method
(V-ITS-S with V-ITS-SG).
This part of ISO 13185 supports ITS applications which are based on ND in vehicles to operate on a
common software interface to a V-ITS-SG to easily exchange vehicle information data among ND, vehicle
V-ITS-SG, and ECUs.
The protocol implementation in the vehicle gateway features the following:
— the deny of access to the vehicle gateway data by unauthorized on-board and off-board test equipment;
— the deny of access to parts of the vehicle gateway data by unauthorized on-board and off-board test
equipment (privacy);
— the identification of the vehicle gateway and the vehicle it is installed in;
— the list of in-vehicle connected ECUs to the vehicle gateway and their data parameters;
— methods to configure the access to vehicle data.
INTERNATIONAL STANDARD ISO 13185-2:2015(E)
Intelligent transport systems — Vehicle interface for
provisioning and support of ITS services —
Part 2:
Unified gateway protocol (UGP) requirements and
specification for vehicle ITS station gateway (V-ITS-SG)
interface
1 Scope
This part of ISO 13185 specifies the requirements of an ASN.1-based protocol between a vehicle-
ITS-Station Gateway (V-ITS-SG) and a nomadic and/or mobile device (ND) to easily exchange vehicle
information data.
The ASN.1-based protocol has been specified to support a wired or wireless connection between the ND
and V-ITS-SG.
The Unified Gateway Protocol (UGP) is used between the V-ITS-SG and the ND. UGP supports several
features in order to provide
— authorization (data privacy),
— secured access,
— V-ITS-SG and in-vehicle ECUs identification,
— real-time vehicle data parameters with identifier and type information in ASN.1 format, and
— enhanced vehicle data parameters with identifier and type information in ASN.1 format.
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 13185−1, Intelligent transport systems — Vehicle interface for provisioning and support of ITS services —
Part 1: General information and use case definition
ISO 14229-2, Road vehicles — Unified diagnostic services (UDS) — Part 2: Session layer services
3 Terms, definitions, symbols, and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 13185−1 and the following apply.
3.1.1
authentication
cryptographic service that provides assurance that the sender of a communication is who they claim to be
Note 1 to entry: Authentication might involve confirming the identity of a person or software program, tracing
the origins of an artefact, ensuring that a product is what its packaging and labelling claims to be.
3.1.2
authorization
right granted by an authority
3.1.3
application layer protocol data unit
A_PDU
group of information added or removed by a layer of the OSI model
Note 1 to entry: Each layer in the model uses the PDU to communicate and exchange information, which can only
be read by the peer layer on the receiving device and is then handed over to the next upper layer after stripping.
Note 2 to entry: The A_PDU (Application layer Protocol Data Unit) is directly constructed from the A_SDU
(Application layer Service Data Unit) and the layer specific control information A_PCI (Application layer Protocol
Control Information).
3.1.4
application layer service data unit
A_SDU
unit of data that has been passed down from an OSI layer to a lower layer and that has not yet been
encapsulated into a protocol data unit (PDU) by the lower layer
Note 1 to entry: It is a set of data that is sent by a user of the services of a given layer and is transmitted semantically
unchanged to a peer service user. A_SDU is the SDU in the OSI layer 7 (application layer).
3.1.5
privacy
choice made by the vehicle owner to grant information access (refer to directive 2002/58/EC dated
12 July 2002).
3.1.6
UGP Client
client implementing the UGP services
Note 1 to entry: For example, ND.
3.1.7
UGP Server
server implementing the UGP services
Note 1 to entry: For example, V-ITS-SG.
3.1.8
unified gateway protocol
UGP
application layer protocol to enable a UGP Client (3.1.6) to access data from the UGP Server (3.1.7)
3.2 Abbreviated terms
API application programming interface
ASN.1 abstract syntax notation one
A_PDU application layer protocol data unit
2 © ISO 2015 – All rights reserved

API application programming interface
A_SDU application layer service data unit
BT bluetooth
C conditional
C-ITS-S central-intelligent transport system-station
CRC cyclic redundancy check
Cvt convention (M, O, C)
DTC diagnostic trouble code
ECU electronic control unit
ITS intelligent transport systems
HCI host controller interface
L2CAP logical link control and adaptation protocol
LC baseband link controller
LMP link manager protocol
M mandatory
ND nomadic device
O optional
OBEX object exchange
PER packed encoding rules
P-ITS-S personal- intelligent transport system-station
RFCOMM radio frequency communication (serial emulation API)
R-ITS-S roadside- intelligent transport system-station
SDP service discovery protocol
UDS unified diagnostic services
UGP unified gateway protocol
U-PER unaligned packed encoding rules
VIN vehicle identification number
V-ITS-SG vehicle-intelligent transport system-station gateway
4 Conventions
This part of ISO 13185 is based on the conventions discussed in the OSI Service Conventions
(ISO/IEC 10731:1994) as they apply for communication services.
These conventions specify the interactions between the service user and the service provider.
Information is passed between the service user and the service provider by service primitives, which
can convey parameters.
The distinction between service and protocol is summarized in Figure 1.
Application of the Sender Application of the Receiver
ServiceName. ServiceName.
ServiceName.
ServiceName.
request conirmation
response-conirmation
indication
ServiceName.
ServiceName.
response
request-conirmation
Call Reply Call Reply
A_SDU with A_SDU with A_SDU with A_SDU with
callSequenceNumber, callSequenceNumber, callSequenceNumber, callSequenceNumber,
[parameter#1, [parameter#1, [parameter#1, [parameter#1,
parameter#2, .] parameter#2, .] parameter#2, .] parameter#2, .]
A_PDU with A_PDU with
Transmission
callSequenceNumber, callSequenceNumber,
to peer entity
[parameter#1, [parameter#1,
parameter#2, .] parameter#2, .]
A_PDU with A_PDU with
callSequenceNumber, Transmission callSequenceNumber,
to peer entity
[parameter#1, [parameter#1,
parameter#2, .] parameter#2, .]
Application layer of the Sender Application layer of the Receiver
Figure 1 — Services and the protocol
This part of ISO 13185 defines services using the six service primitives: request, req_confirm, indication,
response, rsp_confirm, and confirmation.
The request and indication service primitives always have the same format and parameters. Consequently
for all services, the response and confirmation service primitives (except req_confirm and rsp_confirm)
always have the same format and parameters. When the service primitives are defined in this part of
ISO 13185, only the request and response service primitives are listed.
5 Document overview
Figure 2 shows the UGP document structure and automotive protocols and interfaces.
4 © ISO 2015 – All rights reserved
Application Layer Application Layer
Protocol Services
ISO 13185 Vehicle interface for provisioning and support of ITS services
Part 1 Part 2 Part 3 Part 4
General information and use Uniied gateway protocol Uniied gateway protocol Uniied gateway protocol
case deinition (UGP) speciication and (UGP) server and client API (UGP) conformance test
requirements speciication speciication
Automotive application layer protocols
ISO 14229 (all parts) SAE J1939 RP for a Serial ISO 15031 Road vehicles - ISO 27145 Road vehicles -
Road vehicles - Control and Communication between Implementation of World-
Uniied diagnostic services Communications Vehicle vehicle and external test Wide Harmonized On-Board
(UDS) Network equipment for emissions- Diagnostics (WWH-OBD)
related diagnostics communication requirements
ISO 14230 (all parts) Other protocols:
Road vehicles - e.g SAE, vehicle
Keyword protocol 2000 manufacturer speciic, etc.
Communication Interfaces (CI)
ISO 11898 (all parts) ISO 14230-1 ISO 9141-2 Road vehicles - ISO 17458 (all parts)
Road vehicles - Road vehicles - Diagnostic system Road vehicles -
Controller area network Diagnostic over K-Line Part 2: CARB requirements FlexRay communications
(CAN) (Dok-Line) for interchange of digital system
Part 1: Physical layer information
ISO 13400-2 Road vehicles - Other
Diagnostic communication Communication interfaces:
over Internet Protocol e.g SAE, vehicle
(DoIP) - Part 3: IEEE 802.3 manufacturer speciic, etc.
based wired vehicles interface
Figure 2 — UGP document structure and automotive protocols and interfaces
Figure 3 illustrates the implementation of the UGP and UDS document reference according to OSI model
into a V-ITS-SG. Both UGP and UDS use the same session layer services as defined in ISO 14229-2. Non-
UDS based protocols use their own session, transport, and network layer services.
Communication services as they apply to the OSI Service Conventions:
— Application layer:
This part of ISO 13185 specifies the requirements of an ASN.1 based UGP independent of
underlying data link.
— Session layer:
ISO 14229-2 specifies the session layer services. This part of ISO 13185 uses the same session layer
services as ISO 14229-1.
— Transport and Network layer:
Each communication link provides its own set of transport protocols and network layer services.
— Data link and Physical layer:
Each communication link provides its own set of data link and physical layer services.
The OSI layered concept implemented for the ISO 14229 series is the same as the one used for the
ISO 13185 series.
Figure 3 — Implementation of UGP document reference according to OSI model
6 UGP application layer services
6.1 General
Figure 4 illustrates the connection between the ND and V-ITS-SG. UGP provides application layer services
to exchange the data between the Nomadic Device and the V-ITS-SG.
Nomadic Device
UGP
V-ITS-SG
Figure 4 — Connection between ND and V-ITS-SG
6.2 Service primitives
Application layer services are referred to as Unified Gateway Protocol (UGP) services. The application
layer services are used in client-server based systems to perform functions such as test, inspection,
monitoring or diagnosis of on-board vehicle servers. The UGP Client, referred to as the P-ITS-S, R-ITS-S,
or C-ITS-S, uses the application layer UGP services to request data from the UGP Server. The UGP Server
uses the application layer services to send response data, provided by the requested UGP service, back
6 © ISO 2015 – All rights reserved
ISO 13185-3 UGP SAP
ISO 13185-2 UGP (ASN.1)
ISO 13185-2 UGP (ASN.1)
ISO 13185-3 UGP SAP
UGP Handler
In-Vehicle Network Protocols
to the UGP Client. The usage of application layer UGP services is independent from the UGP Client being
an off-board or on-board tester. It is possible to have more than one UGP Client connected.
The UGP server and client API provides a number of services that all have the same general structure.
For each service, six service primitives are specified:
— a service request primitive, used by the client function in the UGP application, to pass data about
a requested UGP service to the diagnostics application layer;
— a service request-confirmation primitive, used by the client function in the UGP application, to
indicate that the data passed in the service request primitive is successfully sent on the V-ITS-SG the
nomadic device is connected to;
— a service indication primitive, used by the UGP application layer, to pass data to the server function
of the server UGP application;
— a service response primitive, used by the server function in the V-ITS-SG UGP application, to pass
response data provided by the requested UGP service to the UGP application layer;
— a service response-confirmation primitive, used by the server function in the V-ITS-SG UGP
application, to indicate that the data passed in the service response primitive is successfully sent on
the V-ITS-SG the nomadic device received the UGP request on;
— a service confirmation primitive used by the UGP application layer to pass data to the client
function in the UGP application.
6.3 Application layer service primitives — Confirmed service
For a given service, the request-confirmation primitive and the response-confirmation primitive always
have the same service data unit. The purpose of these service primitives is to indicate the completion of
an earlier request or response service primitive invocation.
The response-confirm primitive is used by the application layer to indicate an internal event, which is
significant to the server application, and pass communication results of an associated previous service
response to the server function in the V-ITS-SG application.
Figure 5 depicts the application layer service primitives – Confirmed service.
Sender Receiver
Start Start
Application Application
Restart Stop
Layer Layer
Time
Time
P
Client P2
Server
ServiceName.request
Start P
Client_max
P2
Server_max
ServiceName.request-conirm ServiceName.indication
ServiceName.response
ServiceName.confirmation ServiceName.response-conirm
time time
Figure 5 — Application layer service primitives – Confirmed service
Call
message
Reply message
6.4 Format description of service primitives
6.4.1 General definition
All application layer services have the same general format. Service primitives are written in the form:
service_name.type
(
parameter A, parameter B, parameter C
[,parameter 1, .]
)
where
“service_name” is the name of the UGP service (e.g. GetSupported-
Data),
“type” indicates the type of the service primitive (e.g.
request),
“parameter A, .” is the A_SDU (Application layer Service Data Unit)
as a list of values passed by the service primitive
(addressing information),
“parameter A, parameter B, parameter C” are mandatory parameters that shall be included in
all service calls,
“[,parameter 1, .]” are parameters that depend on the specific service
(e.g. parameter 1 can be the GetSupportedData
service). The brackets indicate that this part of the
parameter list can be empty.
6.4.2 Service request and service indication primitives
For each application layer service, service request and service indication primitives are specified
according to the following general format:
service_name.request
(
callSequenceNumber,
timeInMillis,
length, data[, parameter 1,
...],)
The request primitive is used by the client function in the application to initiate the service and pass
data about the requested UGP service to the application layer.
service_name.indication
(
callSequenceNumber,
timeInMillis, length,
data[, parameter 1, .],
)
The indication primitive is used by the application layer to indicate an internal event which is significant
to the UGP Server application and pass data about the requested UGP service to the UGP Server function
of the V-ITS-SG application.
8 © ISO 2015 – All rights reserved

The request and indication primitive of a specific application layer service always have the same
parameters and parameter values. This means, that the values of individual parameters shall not
be changed by the communicating peer protocol entities of the application layer when the data are
transmitted from the UGP Client to the UGP Server. The same values that are passed by the client function
in the UGP Client application to the application layer in the service request call shall be received by the
UGP Server function of the application from the service indication of the peer application layer.
6.4.3 Service response and service confirm primitives
For each application layer service, service response and service confirm primitives are specified
according to the following general format:
service_name.response
(
callSequenceNumber,
timeInMillis, length,
data[, parameter 1, .],
)
The response primitive is used by the server function in the V-ITS-SG application to initiate the service
and pass response data provided by the requested UGP service to the application layer.
service_nam
...