ISO 20078-2:2019 pdf free download – Road vehicles一Extended vehicle (ExVe) web services一 Part 2: Access.
This document defines how to access Resources on a Web services interface of an Offering Party using the Hypertext Transfer Protocol Secure (HTTPS). For such an access, the Representational State Transfer (REST) architectural pattern is chosen as a common way to format Resource paths. Some specific extensions to this pattern are defined to allow for asynchronous Resource requests, such as, for example, forcing readouts of data from a connected vehicle.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 20078-1:2019, Road vehicles — Extended vehicle (ExVe) web services — Part 1: Content ISO 2 0078-3, Road vehicles — Extended vehicle (ExVe) web services — Part 3: Security
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 20078-1 apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at http://www.electropedia.org/
3.2 Abbreviated terms
For the purposes of this document, the abbreviated terms given in ISO 20078-1 apply.
4 Representational State Transfer based Interface
4.1 General
The following defines the requirements on a Representational State Transfer (REST)[] based web service interface using Hypertext Transfer Protocol Secure (HTTPS)[1][2][] based on Transport Layer Security (TLS) to give the Accessing Party secure Access to Resources provided by the Offering Party.
4.10 Error and Information Messaging
Synchronous and asynchronous REST interactions can fail due to various reasons. To enable the Accessing Party to narrow down the cause, the Offering Party provides suitable error messages. An error consists of an Id (exveErrorld) and a short human readable statement (exveErrorMsg).
To avoid confusion, it should be recognized that depending on the interaction pattern, error messaging can be included in unsuccessful requests (e.g., HTTP 4xx) but can also be involved in some HTTP 200 transmissions.
EXAMPLE 1 If in an asynchronous interaction the request fails after some time.
For successful and unsuccessful interactions, the Offering Party can provide additional information with a ‘note’ statement (exveNote).
4.11 Interaction Pattern
4.11.1 Asynchronous
Some functions require an asynchronous interaction pattern (Figure 1). This is for example required when Resources need to be read from the Connected Vehicle rather than being available off-board.
Reading the Connected Vehicle’s current position and speed or the active diagnostics trouble codes could be examples of this. Depending on the architecture and implementation, such operations add a roundtrip delay that is hard to determine due to the connectivity of the vehicle, e.g. network latency, network coverage or vehicle in wrong mode.
To cope with unpredictable response times and avoid keeping the HTTP session open for a long time, the server will respond directly to the client request. Either with the result of the operation or with a location where the client can retrieve (request again) the status of the operation and finally retrieving the result.