ISO 20080:2019/Amd 1:2021

Road vehicles — Information for remote diagnostic support — General requirements, definitions and use cases — Amendment 1

Véhicules routiers — Information pour support de diagnostic à distance — Exigences générales, définitions et cas d'utilisation — Amendement 1

General Information

• Status: Published
• Publication Date: 21-Nov-2021
• ICS: 43.180 - Diagnostic, maintenance and test equipment
• Technical Committee: ISO/TC 22/SC 31 - Data communication
• Drafting Committee: ISO/TC 22/SC 31/WG 6 - Extended vehicle/Remote diagnostics
• Current Stage: 6060 - International Standard published
• Start Date: 22-Nov-2021
• Due Date: 29-Jun-2022
• Completion Date: 22-Nov-2021

Relations

• Amends: ISO 20080:2019 - Road vehicles — Information for remote diagnostic support — General requirements, definitions and use cases
• Effective Date: 11-Dec-2021

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 20080
First edition
2019-03
AMENDMENT 1
2021-11
Road vehicles — Information for
remote diagnostic support — General
requirements, definitions and use
cases
AMENDMENT 1
Véhicules routiers — Information pour support de diagnostic à
distance — Exigences générales, définitions et cas d'utilisation
AMENDEMENT 1
Reference number
ISO 20080:2019/Amd.1:2021(E)
ISO 20080:2019/Amd.1:2021(E)
© ISO 2021
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]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
ISO 20080:2019/Amd.1:2021(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of 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
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31,
Data communication.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
iii
ISO 20080:2019/Amd.1:2021(E)
Road vehicles — Information for remote diagnostic
support — General requirements, definitions and use cases
AMENDMENT 1
Annex A
Replace Annex A with the following:
ISO 20080:2019/Amd.1:2021(E)
Annex A
(informative)
Implementation based on ISO 20078 – Road Vehicles – Extended
Vehicle (ExVe) – Web Services
A.1 Introduction
A.1.1 General
This annex contains a web service specification of the use cases listed in this document. The web
service specification is based on the ISO 20078:2021 series. All web services are defined as REST APIs,
using JSON for the transfer of content.
The ISO 20078:2021 series is indispensable for implementing web services according to this annex.
A.1.2 Security
All REST APIs are using OAuth2 compatible framework for access control, OpenID Connect compatible
framework for identification purposes and HTTPS for securing the transfer, see ISO 20078-3:2021 for
details. The exact details of how to obtain access is described by each offering party.
A.1.3 Error codes
A.1.3.1 ISO 20078
The HTTP status codes (error codes) listed for each REST API are described in ISO 20078-2:2021.
A.1.3.2 General error conditions
General error conditions are valid for all use cases. Table A.1 presents the mapping of error conditions
in 5.5 to REST API errors:
Table A.1 — Mapping of error conditions to REST API
Error condition HTTP status ExveErrorId Example
code
Request currently not 503 20080-1000 {
possible to perform by the
"dtcReadout": {
ExVe
"id": "abcde-12345-ghjke-67474",
"messageTimestamp":
"2016-02-24T09:23:46Z",
"exveErrorId": "20080-1000",
"exveErrorMsg": "Request currently
not possible to perform by the ExVe",
"vehicleId": "12345678909876543"
}
}
ISO 20080:2019/Amd.1:2021(E)
A.1.3.3 Use case specific error conditions
Use case specific errors are mapped to HTTP status codes in each REST API.
A.2 Resources
A web service is exposing access to one or more resources. To be able to access a resource through a
web service, access needs to be granted. This can be done either directly to the resource or through a
container.
Table A.2 maps the ISO 20080 (this document) use cases to REST APIs and resources. In some cases,
mapping of a use case to a REST API provides little standardization benefit, as it is highly offering party
specific.
Table A.2 — Mapping of use cases to REST APIs
UC Use case name REST API Resource(s) Comment
01 Use case discovery resourceReadout Not applicable
02 Identify ECUs installed ecuReadouts ECU readout
in the vehicle
03 Read diagnostic trouble dtcReadouts DTC readout
codes (DTCs)
04 Read readiness codes readinessCodeReadouts Readiness code readout
05 Read DTC snapshot data dtcSnapshotReadout DTC snapshot readout
06 Read selected parameterReadout Parameter readout
diagnostic
parametric
dynamic data
07 Read malfunction malfunctionIndicatorReadout Malfunction indicator
indicator status readout
08 Clear DTCs clearDtcJob Clear DTC job
09 Adjust the settings of a Not applicable/no Not applicable System setting input
selected system standardized API due to and result are offering
differences between party specific.
offering parties.
10 Activation of actuators Not applicable/no Not applicable Actuator input and
standardized API due to result are offering
differences between party specific.
offering parties.
11 Activate a self-test Not applicable/no Not applicable Self-test input and
routine standardized API due to result are offering
differences between party specific.
offering parties.
ISO 20078-2:2021 defines new syntax for resource versioning (used in Accept and Content-Type HTTP
headers). Existing implementations of ISO 20080 based on the ISO 20078:2019 series version can still
be used. For new implementations, support of the ISO 20078:2021 series is recommended (see Table A.3
for details).
ISO 20080:2019/Amd.1:2021(E)
Table A.3 — Mapping of REST API resource representation used in ISO 20080:2019 and
ISO 20080:2019/Amd.1:2021 versions
UC REST API Resource version according to Resource version according to
ISO 20078-2:2019 ISO 20078-2:2021
01 resourceReadout application/x.exve.org.resourcereadout.v1+json application/json; exve-resourceversion=
resourcereadout.v1.0
02 ecuReadouts application/x.exve.org.ecureadout.v1+json application/json; exve-resourceversion=
ecureadout.v1.0
03 dtcReadouts application/x.exve.org.dtcreadout.v1+json application/json; exve-resourceversion=
dtcreadout.v1.0
04 readinessCodeReadouts application/x.exve.org.readinesscodereadout.v1+json application/json; exve-resourceversion=
readinesscodereadout.v1.0
05 dtcSnapshotReadout application/x.exve.org.dtcsnapshotreadout.v1+json application/json; exve-resourceversion=
dtcsnapshotreadout.v1.0
06 parameterReadout application/x.exve.org.parameterreadout.v1+json application/json; exve-resourceversion=
parameterreadout.v1.0
malfunctionIndicatorRead application/x.exve.org.malfunctionIndicatorreadout. application/json; exve-resourceversion=
out v1+json malfunctionindicatorreadout.v1.0
08 clearDtcJob application/x.exve.org.cleardtcjob.v1+json application/json; exve-resourceversion=
cleardtcjob.v1.0
A.3 REST API information model
The rest API information model in Figure A.1 is compiled from the use cases in this document and used
as a base for designing the REST APIs.
Figure A.1 — REST API information model
ISO 20080:2019/Amd.1:2021(E)
A.4 REST APIs
A.4.1 Use case 01 – resourceReadout
The resourceReadout API follows the asynchronous interaction pattern, as the processing time of the
request can vary dependent on the offering party implementation (see Figure A.2). In some cases, it is
possible to return the result immediately, whereas sometimes the accessing party needs to poll the API
until the result is ready.
The accessing party starts by posting a resource readout request (see Table A.4). If the result is available
immediately, the result is returned directly (see Table A.5). If the result is not available immediately, a
status is returned instead of the readout. The accessing party is supposed to poll the request status
until the processing is completed. When the processing is completed, the accessing party will receive
the result.
The readout status and the completed readout will be available for a limited time after being created.
This time is specified by the offering party.
Figure A.2 — resourceReadouts sequence diagram
Table A.4 — POST resourceReadout
POST vehicles/{vehicleId}/resourceReadouts
Description This API creates a readout of available resources to the accessing party for one vehicle. If the
result is available immediately, the result is returned. If the result is not available, a location
to the resource readout is returned. This location shall be polled until the result is available.
Parameters vehicleId string required The vehicle identifier of the vehicle to read from
ISO 20080:2019/Amd.1:2021(E)
Table A.4 (continued)
Request Host required According to HTTP/1.1 RFC 2616
headers
Authorization required Bearer {token}
Accept required application/json; exve-resourceversion=resourcereadout.v1.0;
charset=utf-8
Response Location Absolute URI of the /resourceReadouts endpoint
headers
Response 201 Example (result available immediately):
(success)
{
"resourceReadout": {
"id": "abcde-12345-ghjke-67474",
"asyncStatus": "Complete",
"messageTimestamp": "2016-02-24T09:23:46Z",
"vehicleId": "12345678909876543",
"resources": [
{
"name": "DTC Readout",
"version": "1",
"api":
"https://example.org/vehicles/12345678909876543/dtcReadouts"
},
{
"name": "ECU Readout",
"version": "1",
"api":
"https://example.org/vehicles/12345678909876543/ecuReadouts"
}
]
}
}
202 Result is not available immediately. Location of resourceReadout will be returned,
e.g. vehicles/{vehicleId}/resourceReadouts/{id}, see Location header.
Error codes 400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
406 Not Acceptable
500 Internal Server Error
501 Not Implemented
503 Service Unavailable
505 Version Not Supported
Access Any resource Access to any resource will give access to this API.
JSON schema See Clause A.5.
ISO 20080:2019/Amd.1:2021(E)
Table A.5 — GET resourceReadout
GET vehicles/{vehicleId}/resourceReadouts/{id}
Description This API returns a readout of available resources to the accessing party for one vehicle. The id
of the readout is returned when posting the request. If the resource readout is not completed,
the readout status is returned. If the resource readout is completed, the result is returned.
Parameters vehicleId string required The vehicle identifier of the vehicle to read from
id string required Id of the DTC readout
Request Host required According to HTTP/1.1 RFC 2616
headers
Authorization required Bearer {token}
Accept required application/json; exve-resourceversion=resourcereadout.v1.0;
charset=utf-8
Response Content-Type application/json; exve-resourceversion= resourcereadout.v1.0;charset=utf-8
headers
Response 200 Example (result available):
(success)
{
"resourceReadout": {
"id": "abcde-12345-ghjke-67474",
"asyncStatus": "Complete",
"messageTimestamp": "2016-02-24T09:23:46Z",
"vehicleId": "12345678909876543",
"resources": [
{
"name": "DTC Readout",
"version": "1",
"api":
"https://example.org/vehicles/12345678909876543/dtcReadouts"
},
{
"name": "ECU Readout",
"version": "1",
"api":
"https://example.org/vehicles/12345678909876543/ecuReadouts"
}
]
}
}
ISO 20080:2019/Amd.1:2021(E)
Table A.5 (continued)
Example (result not available):
{
"resourceReadout": {
"id": "abcde-12345-ghjke-67474",
"asyncStatus": "InProgress",
"asyncWait": 10000,
"asyncEstimatedComplete": "2016-02-24T09:24:00Z",
"messageTimestamp": "2016-02-24T09:23:46Z",
"vehicleId": "12345678909876543"
}
}
Error codes 400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
406 Not Acceptable
500 Internal Server Error
501 Not Implemented
503 Service Unavailable
505 Version Not Supported
Access Any resource Access to any resource will give access to this API.
JSON schema See Clause A.5.
A.4.2 Use case 02 – ecuReadouts
The ecuReadout API follows the asynchronous interaction pattern, as the processing time of the request
can vary dependent on the offering party implementation (see Figure A.3). In some cases, it is possible
to return the result immediately, whereas sometimes the accessing party needs to poll the API until the
result is ready.
The accessing party starts by posting an ECU readout request (see Table A.6). If the result is available
immediately, the result is returned directly. If the result is not available immediately, a status i
...