ISO 13185-3:2018

Intelligent transport systems — Vehicle interface for provisioning and support of ITS Services — Part 3: Unified vehicle interface protocol (UVIP) server and client API specification

This document specifies the server and client APIs of the Unified Gateway Protocol (UGP). Figure 1 shows an overview of the UGP client and server API. A UGP client application on a P-ITS-S communicates with a UGP server application on a V-ITS-S. The UGP client application implements the UGP client API using ISO 13185-2. The UGP server application implements the UGP server API using ISO 13185-2.

Systèmes intelligents de transport — Interface véhicule pour la fourniture et le support de services ITS — Partie 3: Serveur du protocole unifié pour l'interface véhicule (UVIP) et spécification de l'API client

General Information

• Status: Published
• Publication Date: 30-May-2018
• ICS: 03.220.01 - Transport in general
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 17 - Nomadic Devices in ITS Systems
• Current Stage: 9060 - Close of review
• Completion Date: 02-Dec-2028

Relations

• Consolidated By: ISO 16410-2:2018 - Electronic fee collection — Evaluation of equipment for conformity to ISO 17575-3 — Part 2: Abstract test suite
• Effective Date: 06-Jun-2022

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 13185-3
First edition
2018-06
Intelligent transport systems —
Vehicle interface for provisioning and
support of ITS Services —
Part 3:
Unified vehicle interface protocol
(UVIP) server and client API
specification
Systèmes intelligents de transport — Interface véhicule pour la
fourniture et le support de services ITS —
Partie 3: Serveur du protocole unifié pour l'interface véhicule (UVIP)
et spécification de l'API client
Reference number
©
ISO 2018
© ISO 2018
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Fax: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii © ISO 2018 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, symbols and abbreviated terms . 2
4 Abbreviated terms . 3
5 Conventions . 3
6 UGP API concept . 4
6.1 UGP client and server architecture . 4
6.2 UGP communication flow . 5
6.3 UGP interfaces and service primitives . 6
7 UGP Java client API . 7
7.1 UGP Java client API requests . 7
7.1.1 Overview . 7
7.1.2 authenticationReq . 8
7.1.3 getSupportedDataReq . 8
7.1.4 getValueReq . . 9
7.1.5 setValueReq .11
7.1.6 controlValueReq .11
7.1.7 getDtcInfoReq .12
7.1.8 clearDtcInfoReq .13
7.1.9 enablePassThruReq . .14
7.1.10 listFileReq .14
7.1.11 manageFileUploadReq .15
7.1.12 manageFileDownloadReq .16
7.1.13 manageFileDeleteReq .16
7.1.14 resetReq .17
7.1.15 stopServiceReq .17
7.2 UGP Java Client API confirmations .18
7.2.1 Overview .18
7.2.2 authenticationConf .18
7.2.3 getSupportedDataConf .19
7.2.4 getValueConf .20
7.2.5 controlValueConf .21
7.2.6 getDtcInfoConf .21
7.2.7 listFileConf .22
7.2.8 manageFileConf .23
7.2.9 positiveConf.23
7.2.10 negativeConf .24
8 UGP Java server API .24
8.1 UGP Java server API indications .24
8.1.1 Overview .24
8.1.2 authenticationInd.25
8.1.3 getSupportedDataInd .25
8.1.4 getValueInd .26
8.1.5 setValueInd .27
8.1.6 controlValueInd .28
8.1.7 getDtcInfoInd .28
8.1.8 clearDtcInfoInd .29
8.1.9 enablePassThruInd .30
8.1.10 listFileInd .30
8.1.11 manageFileInd .31
8.1.12 resetInd .31
8.1.13 stopServiceInd .32
8.2 UGP Java server API responses .32
8.2.1 Overview .32
8.2.2 authenticationResp .33
8.2.3 getSupportedDataResp .33
8.2.4 getValueResp .34
8.2.5 controlValueResp.34
8.2.6 getDtcInfoResp .35
8.2.7 listFileResp . .35
8.2.8 manageFileResp .36
8.2.9 positiveResp .36
8.2.10 negativeResp .37
Bibliography .38
iv © ISO 2018 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
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 voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following
URL: www .iso .org/iso/foreword .html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
Introduction
This document has been established to define the UGP client and server Java API of a common software
interface to a vehicle UGP server to easily exchange vehicle information data amongst nomadic and/or
mobile devices, cloud servers, vehicle servers 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.
A Nomadic Device (ND) becomes a Personal ITS station (P-ITS-S) if a Hardware Security Module (HSM)
and software, that prohibits unauthorized access to an ITS-secured domain inside the ND, has been
implemented.
This document defines the UGP client and server Java API protocol between the P-ITS-S and the UGP
server in the vehicle.
The protocol specified in this document 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 document may be used by vehicle manufacturers to implement an interoperable UGP server in on-
board communications modules that are allowed to interface with P-ITS-S(s). Through this interface,
P-ITS-S(s) can access in-vehicle information provided to the UGP server. The means by which the UGP
server obtains the in-vehicle information is outside the scope of this document.
The P-ITS-S applications need vehicle information data through an in-vehicle interface access method.
This document supports ITS applications based on a client-server model which allows clients on P-ITS-S
to obtain data from ECUs in the in-vehicle networks (IVNs) through a common interface to a server
located in a Vehicular ITS station (V-ITS-S) which in turn is acting as a gateway to the IVNs. The protocol
implementation in the vehicle's UGP server may include the following features:
— the denial of access to the vehicle's UGP server data by unauthorized on-board and off-board test
equipment;
— the denial of access to parts of the vehicle's UGP server data by unauthorized on-board and off-
board test equipment (privacy);
— the identification of the vehicle's UGP server and the vehicle it is installed in;
— the list of in-vehicle connected ECUs to the vehicle's UGP server and their data parameters;
— methods to configure the access to vehicle data.
vi © ISO 2018 – All rights reserved

INTERNATIONAL STANDARD ISO 13185-3:2018(E)
Intelligent transport systems — Vehicle interface for
provisioning and support of ITS Services —
Part 3:
Unified vehicle interface protocol (UVIP) server and client
API specification
1 Scope
This document specifies the server and client APIs of the Unified Gateway Protocol (UGP). Figure 1
shows an overview of the UGP client and server API. A UGP client application on a P-ITS-S communicates
with a UGP server application on a V-ITS-S. The UGP client application implements the UGP client API
using ISO 13185-2. The UGP server application implements the UGP server API using ISO 13185-2.
Figure 1 — UGP client and server API
NOTE This document does not define the UGP client and server API in other languages than Java.
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 (ITS) — Vehicle interface for provisioning and support of ITS
services — Part 1: General information and use case definition
ISO 13185-2, Intelligent transport systems (ITS) — 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
ISO 21217, Intelligent transport systems — Communications access for land mobiles (CALM) — Architecture
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, ISO 21217 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http: //www .electropedia .org/
— ISO Online browsing platform: available at http: //www .iso .org/obp
3.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 it's packaging and labelling claims to be.
3.2
authorisation
prescription that a particular behaviour shall not be prevented
[SOURCE: ISO 17419, 3.1]
3.3
nomadic device
ND
provides communications connectivity via equipment such as cellular telephones, mobile wireless
broadband (WIMAX, HC-SDMA, etc.), WiFi, etc. and includes short range links, such as Bluetooth, Zigbee
Note 1 to entry: Nomadic devices do not necessarily implement ITS-specified security, e.g. hardware security
module.
3.4
privacy
choice made by the vehicle owner to grant information access for a special tool or user, or if the data
should be used in the vehicle/off-board systems or not
Note 1 to entry: The privacy/authorization information is kept as master information off-board and synchronised
to the on-board V-ITS-S.
3.5
UGP client
entity that implements the UGP client services
EXAMPLE ND, P-ITS-S.
3.6
UGP server
entity that implements the UGP server services
EXAMPLE V-ITS-S.
3.7
unified gateway protocol
UGP
application layer protocol to enable UGP clients to access data from the UGP server
2 © ISO 2018 – All rights reserved

4 Abbreviated terms
API application programming interface
ASN.1 abstract syntax notation one
A_PDU application layer protocol data unit
A_SDU application layer service data unit
Conf confirmation
CRC cyclic redundancy check
DTC diagnostic trouble code
ECU electronic control unit
GUI graphical user interface
Ind indication
ITS intelligent transport systems
ND nomadic device
OSI open systems interconnection
P-ITS-S personal – intelligent transport system – station
Req request
Resp response
UGP unified gateway protocol
V-ITS-S vehicle – intelligent transport system – station
5 Conventions
This document is based on the conventions discussed in the OSI Service Conventions (ISO/
[1]
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
may convey parameters.
Figure 2 shows a high level flow diagram of UGP.
Figure 2 — UGP client-server relationship
This document defines services using the six service primitives: request, req_confirm, indication,
response, rsp_confirm and confirmation as defined in ISO 13185-2:2015, Clause 6.
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 document, only the request and response service primitives are listed.
6 UGP API concept
6.1 UGP client and server architecture
Figure 3 shows the UGP client and server architecture. On the P-ITS-S there is a UGP client application
and on the V-ITS-S there is a UGP server application.
The UGP client application uses the interface IUGPRequest to request services and the interface
IUGPConfirmation to receive the corresponding confirmation. In the confirmation implementation
another request can be called or the GUI can be updated. The UGPRequest Implementation shall encode
the request into a corresponding ISO 13185-2 Call. Before calling the IUGPConfirmation the UGP client
application shall decode and interpret the ISO 13185-2 Reply.
The UGP server application shall decode ISO 13185-2 Calls and interpret it to call its interface
IUGPIndication. The corresponding implementation shall get data, DTCs, etc. and to create the
corresponding response by calling the interface IUGPResponse. The UGPResponseImplementation shall
encode the response into an ISO 13185-2 Reply.
4 © ISO 2018 – All rights reserved

Figure 3 — UGP client and server architecture
6.2 UGP communication flow
Figure 4 shows the UGP communication flow. The UGP client application shall create a connection to
the V-ITS-Ss UGP server application. Then it calls an authenticationRequest which is encoded into an
ISO 13185-2 authenticationCall. The UGP server application decodes the authenticationCall and calls
the authenticationIndication. If the authenticationKey is not OK for the V-ITS-S, the UGPIndication
implementation creates a negativeResponse which will be decoded as ISO 13185-2 globalNegativeReply.
The UGP client application decodes the globalNegativeReply and calls a negativeConfirmation. Usually
the UGP client application should update its GUI with an error message “Not allowed to access”.
Figure 4 — UGP communication flow
If the authenticationKey is OK for the V-ITS-S, the UGPIndication implementation calls an
authenticationResponse which will be decoded as ISO 13185-2 authenticationReply. The UGP
client application decodes the authenticationReply and calls an authenticationConfirmation. The
authenticationConfirmation can indicate the authentication authorization bits but shall call now a
getSupportedDataRequest.
The UGP client application encodes the getSupportedDataRequest into an ISO 13185-2
getSupportedDataCall. The UGP server application receives and decodes it and calls
a getSupportedDataIndication which creates the requested supported data infos in a
getSupportedDataResponse. This is decoded into an ISO 13185-2 getSupportedDataReply.
The UGP client application receives and decodes the getSupportedDataReply and calls a
getSupportedDataConfirmation.
The data parameters or DTCs can be requested by getValueReq or getDtcInfoReq, etc.
6.3 UGP interfaces and service primitives
Table 1 defines the UGP interfaces and service primitives.
Table 1 — UGP interfaces and service primitives
IUGPRequest IUGPIndication IUGPResponse IUGPConfirmation
authenticationReq authenticationInd authenticationResp authenticationConf
getSupportedDataReq getSupportedDataInd getSupportedDataResp getSupportedDataConf
getValueReq getValueInd getValueResp getValueConf
setValueReq setValueInd positiveResp positiveConf
controlValueReq controlValueInd controlValueResp controlValueConf
getDtcInfoReq getDtcInfoInd getDtcInfoResp getDtcInfoConf
clearDtcInfoReq clearDtcInfoInd positiveResp positiveConf
6 © ISO 2018 – All rights reserved

Table 1 (continued)
IUGPRequest IUGPIndication IUGPResponse IUGPConfirmation
enablePassThruReq enablePassThruInd positiveResp positiveConf
listFileReq listFileInd listFileResp listFileConf
manageFileUploadReq manageFileInd manageFileResp manageFileConf
manageFileDownloadReq manageFileInd manageFileResp manageFileConf
manageFileDeleteReq manageFileInd manageFileResp manageFileConf
resetReq resetInd positiveResp positiveConf
stopServiceReq stopServiceInd positiveResp positiveConf
7 UGP Java client API
7.1 UGP Java client API requests
7.1.1 Overview
Corresponding to the UGP services defined in ISO 13185-2, the UGP Java client requests API
(IUGPRequest) contains request services that can be called by any application to execute a UGP service
(Req). The UGP Java client API confirmations (see 7.2) handle the corresponding replies.
Table 2 defines the UGP Java client API requests (IUGPRequest).
Table 2 — UGP Java client API requests (IUGPRequest)
Service API definition
authenticationReq UGPPackage authenticationReq(String authenticationKey) throws VIException;
getSupportedDataReq UGPPackage getSupportedDataReq(SupportedDataFilter supportedDataFilter)
throws VIException;
UGPPackage getSupportedDataReq(SupportedDataFilter supportedDataFilter,
Integer[] ecuIds, AccessType accessType, Integer dataParamProperty)
throws VIException;
getValueReq UGPPackage getValueReq(int testInterval, Integer rvId, ComplexCondition condition)
throws VIException;
UGPPackage getValueReq(int testInterval, Integer[] rvIds, ComplexCondition condi-
tion)
throws VIException;
UGPPackage getValueReq(int testInterval, Vector mappings,
ComplexCondition condition) throws VIException;
setValueReq UGPPackage setValueReq(Vector valueMappings)
throws VIException;
controlValueReq UGPPackage controlValueReq(int testInterval, Integer rvId,
Vector values, ExecutionType execute) throws VIException;
UGPPackage controlValueReq(int testInterval, Integer[] rvIds,
Vector values, ExecutionType execute) throws VIException;
getDtcInfoReq UGPPackage getDtcInfoReq(int testInterval, Integer ecuId, boolean withEnvData,
ComplexCondition condition) throws VIException;
UGPPackage getDtcInfoReq(int testInterval, Integer[] ecuIds, boolean withEnvData,
ComplexCondition condition) throws VIException;
clearDtcInfoReq UGPPackage clearDtcInfoReq(Integer ecuId) throws VIException;
UGPPackage clearDtcInfoReq(Integer[] ecuIds) throws VIException;
enablePassThruReq UGPPackage enablePassThruReq(String label, String key) throws VIException;
Table 2 (continued)
Service API definition
listFileReq UGPPackage listFileReq(FileType fileType) throws VIException;
manageFileUploadReq UGPPackage manageFileUploadReq(FileType fileType, File f) throws VIException;
UGPPackage manageFileDownloadReq(FileType fileType, String filename)
throws VIException;
UGPPackage manageFileDeleteReq(FileType fileType, String filename) throws VIEx-
ception;
resetReq UGPPackage resetReq(ResetType resetType) throws VIException;
stopServiceReq UGPPackage stopServiceReq(int callSequenceNumber) throws VIException;
All request services return a UGPPackage containing the ASN.1 message to send to the UGP server or
throw a VIException if one of the parameters is invalid.
7.1.2 authenticationReq
Table 3 defines the authentication request service.
Table 3 — Definition of the authentication request service
SP authenticationReq Initiates the communication to the V-ITS-S by requesting the users V-ITS-S
authentication key.
Conf positiveConf
Param Name Type Description
authenticationKey
String Public key for access to a V-ITS-S
UGPPackage authenticationReq(String authenticationKey) throws VIException;
API
UGPClient.authenticationReq(“0vrmYdc6ziscBdMhGphiT6m0a0D2dNLCnETRSlg”);
e.g.
ASN.1
AuthenticationCall:: = SEQUENCE {
authenticationKey  String,
...
}
7.1.3 getSupportedDataReq
Table 4 defines the getSupportedData request service.
8 © ISO 2018 – All rights reserved

Table 4 — Definition of the getSupportedData request service
SP getSupportedDataReq Request the supported data parameters from the V-ITS-S.
Conf getSupportedDataConf
Param Name Type Description
supportedDataFilter SupportedDataFilter
Filters the supported data to: vehicle-info-
(Enumeration)
only, with-ecu-data, without-ecu-data
ecuIds Integer[]
List of the ECU identifer of the in-vehicle network
ECUs from where the data parameters should be
retrieved. If ecuList is empty or null the data pa-
rameters are not filtered by ECU.
accessType AccessType
Filters the supported data parameters to the spec-
ified access type. If no accessType is defined the
access types are not filtered.
dataParamProperty Integer
Filters the supported data parameters to
the specified data parameter property. If no
dataParamProperty is defined, the data pa-
rameter properties are not filtered.
API UGPPackage getSupportedDataReq(SupportedDataFilter supportedDataFilter,
Integer[] ecuIds, AccessType accessType, Integer dataParamProperty)
throws VIException;
enum SupportedDataFilter {
vehicle_info_only(0), with_ecu_data(1), without_ecu_data(2);
}
/** predefined AccessTypes **/
static AccessType read_only, write_only, read_write, execute, write_
internal,
user_input;
UGPClient.getSupportedDataReq(SupportedDataFilter.without-ecu-data, null,
e.g.
null, null);
UGPClient.getSupportedDataReq(SupportedDataFilter.with-ecu-data, new
int[] { 17 },
AccessType.read-only, null);
GetSupportedDataCall:: = SEQUENCE {
ASN.1
supportedDataFilter SupportedDataFilter         DEFAULT with-
ecu-data,
ecuList       SEQUENCE OF Identifier        OPTIONAL,
accessType     AccessType             OPTIONAL,
dataParamProperty  DataParamProperty          OPTIONAL,
...
}
7.1.4 getValueReq
Table 5 defines the getValue request service.
Table 5 — Definition of the getValue request service
SP getValueReq Request the data parameter values from the V-ITS-S.
Conf getValueConf
Param Name Type Description
testInterval int
If testInterval is 0 the result should be sent only once
if the condition is true or not set. If testInterval > 0 it
contains a number of milliseconds and each time the
testInterval has expired and the condition is true or
not set the getValueConf will be sent.
rvId Integer
RvId of a single data parameter to retrieve.
rvIds Integer[]
List of rvIds of the data parameters to retrieve.
mappings Vector
List of mappings between ecuId and rvId of the cor-
responding data parameters.
condition ComplexCondition Condition that will be checked once (if testInterval = 0)
or every testInterval milliseconds (testInterval > 0).
UGPPackage getValueReq(int testInterval, Integer rvId,
API
ComplexCondition condition) throws VIException;
UGPPackage getValueReq(int testInterval, Integer[] rvIds,
ComplexCondition condition) throws VIException;
UGPPackage getValueReq(int testInterval, Vector
mappings,
ComplexCondition condition) throws VIException;
UGPClient.getValueReq(0, 2344, null);
e.g.
UGPClient.getValueReq(0, 20025, null);
UGPClient.getValueReq(0, new Integer[] { 1002, 7368, 2341, 1123 }, null);
Vector mappings = new Vector;
UGPClient.addDataParamMapping(mappings, 17, 1002);
UGPClient.addDataParamMapping(mappings, 17, 7368);
UGPClient.addDataParamMapping(mappings, 51, 2341);
ComplexCondition conditionECTgt110 = UGPClient.
createDataParamCondition(51, 2341,
OperatorType.gt, DataParamCondValue.numeric(1100));
UGPClient.getValueReq(5000, mappings, conditionECTgt180);
GetValueCall:: = SEQUENCE {
ASN.1
testInterval    SNUM32,
dataParamList    SEQUENCE OF Identifier         OPTIONAL,
dataParamMapping  SEQUENCE OF DataParamMapping     OPTIONAL,
condition      ComplexCondition           OPTIONAL,
...
}
10 © ISO 2018 – All rights reserved

7.1.5 setValueReq
Table 6 defines the setValue request service.
Table 6 — Definition of the setValue request service
SP setValueReq Request the data parameter values from the V-ITS-S.
Conf positiveConf
Pa- Name Type Description
rame-
valueMapping Vector List of data parameter value mappings
ter

setValueReq(Vector valueMappings)
API
throws VIException;
Vector valueMappings = new Vector e.g.
ng>();
UGPClient.addDataParamValueMapping(17, 7368, DataParamValue.enumString(0));
UGPClient.setValueReq(valueMappings);
SetValueCall:: = SEQUENCE {
ASN.1
valueMapping    SEQUENCE OF DataParamValueMapping,
...
}
7.1.6 controlValueReq
Table 7 defines the controlValue request service.
Table 7 — Definition of the controlValue request service
SP controlValueReq Request the data parameter values from the V-ITS-S.
Conf controlVal-
ueConf
Pa- Name Type Description
ram-
testInterval int
If testInterval is 0 the confirmation is sent only once when the
eter
control function completes. If testInterval > 0 the confirmation
is sent each time the testInterval in milliseconds has expired.
rvId Integer
RvId of a single control-function.
rvIds Integer[]
List of rvIds of the control-functions.
mappings Vector
List of mappings between ECU and control-function to start
or stop.

values Vector
List of data parameter values as parameters for the control
function.

execute ExecutionType
Type of the execution with values start and stop to start or
stop the control function.
Table 7 (continued)
SP controlValueReq Request the data parameter values from the V-ITS-S.
Conf controlVal-
ueConf
UGPPackage controlValueReq(int testInterval, Integer rvId,
API
Vector values, ExecutionType execute) throws
VIException;
UGPPackage controlValueReq(int testInterval, Integer[] rvIds,
Vector values, ExecutionType execute) throws
VIException;
UGPPackage controlValueReq(int testInterval, Vector v,
Vector values, ExecutionType execute) throws
VIException;
Vector mappings = new Vector();
e.g.
UGPClient.addDataParamMapping(mappings, 22, 0xfa002f00l);
Vector values = new Vector();
values.addElement(DataParamValue.lnumeric(0xfd009b00l));
values.addElement(DataParamValue.enumString(3));
values.addElement(DataParamValue.numeric(60));
UGPClient.controlValueReq(0, mappings, values, ExecutionType.start);
values = new Vector();
values.addElement(DataParamValue.lnumeric(0xfd000155l));
values.addElement(DataParamValue.enumString(3));
values.addElement(DataParamValue.numeric(7));
values.addElement(DataParamValue.error(0)); //4 times .
UGPClient.controlValueReq(0, mappings, values, ExecutionType.start);
ControlValueCall:: = SEQUENCE {
ASN.1
testInterval    SNUM32                 DEFAULT 0,
dataParamList    SEQUENCE OF Identifier         OPTIONAL,
dataParamMapping  SEQUENCE OF DataParamMapping      OPTIONAL,
value        SEQUENCE OF DataParamValue,
execute       ExecutionType,
...
}
ExecutionType:: = ENUMERATED { start, stop, .
}
7.1.7 getDtcInfoReq
Table 8 defines the getDtcInfo request service.
12 © ISO 2018 – All rights reserved

Table 8 — Definition of the getDtcInfo request service
SP getDtcInfoReq Request the current DTCs.
Conf getDtcInfoConf
Param Name Type Description
testInterval int
If testInterval is 0 the result should be sent only once if the condition is
true or not set. If testInterval > 0 it contains a number of milliseconds
and each time the testInterval has expired and the condition is true
or is not set the getDtcInfoConf will be sent.
ecuId Integer Filters the DTCs to the ECU defined by ecuId. If ecuId is null, the DTCs
of all ECUs are retrieved.
ecuIds Integer[]
Filters the DTCs to the ECus defined by the ecuIds. If ecuIds are null,
the DTCs of all ECUs are retrieved.
withEnvData boolean
false: retrieve no environment data
true: retrieve configured environment data
condition ComplexCondition
Condition that will be checked once (if testInterval = 0) or every
testInterval milliseconds (testInterval > 0).
UGPPackage getDtcInfoReq(int testInterval, int ecuId, boolean withEnvData,
API
ComplexCondition condition) throws VIException;
UGPPackage getDtcInfoReq(int testInterval, int[] ecuIds, boolean withEnvData,
ComplexCondition condition) throws VIException;
UGPClient.getDtcInfoReq(0, 32, false, null);
e.g.
UGPClient.getDtcInfoReq(10000, null, true, null);
GetDtcInfoCall:: = SEQUENCE {
ASN.1
testInterval    SNUM32                 DEFAULT 0,
rdtcBaseId     UNUM16                 OPTIONAL,
rdtcSymptomId    UNUM16                 OPTIONAL,
ecuList       SEQUENCE OF Identifier         OPTIONAL,
withEnvData     BOOLEAN                DEFAULT FALSE,
condition      ComplexCondition            OPTIONAL,
...
}
7.1.8 clearDtcInfoReq
Table 9 defines the clearDtcInfo request service.
Table 9 — Definition of the clearDtcInfo request service
SP clearDtcIn- Request to clear the DTCs of the defined ECUs.
foReq
Conf positiveConf
Pa- Name Type Description
ram-
ecuId Integer Clears the DTCs of the defined ECU. If ecuId is null, the DTCs of all ECUs
eter
are cleared.
ecuIds Integer[]
Clears the DTCs of the defined ECUs. If ecuIds are null, the DTCs of all
ECUs are cleared.
Table 9 (continued)
SP clearDtcIn- Request to clear the DTCs of the defined ECUs.
foReq
Conf positiveConf
UGPPackage clearDtcInfoReq(Integer ecuId) throws VIException;
API
UGPPackage clearDtcInfoReq(Integer[] ecuIds) throws VIException;
UGPClient.clearDtcInfoReq(null);
e.g.
UGPClient.clearDtcInfoReq(206);
ASN.1 ClearDtcInfoCall:: = SEQUENCE {
ecuList       SEQUENCE OF Identifier         OPTIONAL,
...
}
7.1.9 enablePassThruReq
Table 10 defines the enablePassThru request service.
Table 10 — Definition of the enablePassThru request service
SP enablePassThru- Request to enable or disable the pass thru modus.
Req
Conf positiveConf
Pa- Name Type Description
ram-
label String
Label of the pass thru seed to enable or disable the pass thru
eter
key String
Key to enable the pass thru; if the key is null, the pass thru will be disabled
UGPPackage enablePassThruReq(String label, String key) throws VIException;
API
UGPClient.enablePassThruReq(“ENH_DIAG_PASS_THRU_SEED”, “flkja0932jdla9323jddff3d”);
e.g.
UGPClient.enablePassThruReq(“ECU_PRG_PASS_THRU_SEED”, null);
EnablePassThruCall:: = SEQUENCE {
ASN.1
label        String,
key         String                 OPTIONAL
}
7.1.10 listFileReq
Table 11 defines the listFile request service.
14 © ISO 2018 – All rights reserved

Table 11 — Definition of the listFile request service
SP listFileReq Request a list of files of the given fileType from the V-ITS-S.
Conf listFileConf
Pa- Name Type Description
ram-
fileType FileType
Type of the file: core, configuration, log, snapshot,
eter
calibration.
UGPPackage listFileReq(FileType fileType) throws VIException;
API
enum FileType {
core(0), configuration(1), log(2), snapshot(3), calibration(4);
}
UGPClient.listFileReq(FileType.configuration);
e.g.
ListFileCall:: = SEQUENCE {
ASN.1
fileType      FileType,
...
}
FileType:: = ENUMERATED { core, configuration, log, snapshot, calibration, .
}
7.1.11 manageFileUploadReq
Table 12 defines the manageFileUpload request service.
Table 12 — Definition of the manageFileUpload request service
SP manageFileUp- Request to manage a file.
loadReq
Conf manageFileConf
Pa- Name Type Description
rame-
fileType FileType
Type of the file: core, configuration, log, snapshot,
ter
calibration.
f File
The file to upload.
Table 12 (continued)
SP manageFileUp- Request to manage a file.
loadReq
Conf manageFileConf
UGPPackage manageFileUploadReq(FileType type, File f) throws VIException;
API
enum FileTyp
...