ISO 17215-2:2014

Road vehicles — Video communication interface for cameras (VCIC) — Part 2: Service discovery and control

ISO 17215-2:2014 specifies how services can be discovered and controlled. This functionality is located mainly in layer 5 of the OSI model. Both discovery and control are implemented using the scalable service oriented middlewire over IP (SOME/IP). The general terminology defined in ISO 17215‑1 is also used in ISO 17215-2:2014.

Véhicules routiers — Interface de communication vidéo pour caméras (ICVC) — Partie 2: Contrôle et découverte du service

General Information

• Status: Published
• Publication Date: 05-May-2014
• ICS: 43.040.15 - Car informatics. On board computer systems
• Technical Committee: ISO/TC 22/SC 31 - Data communication
• Drafting Committee: ISO/TC 22/SC 31/WG 4 - Network applications
• Parallel Committee: ISO/TC 43/SC 1 - Noise
• Current Stage: 9093 - International Standard confirmed
• Completion Date: 01-Oct-2019

Relations

• Consolidated By: ISO 25649-6:2017 - Floating leisure articles for use on and in the water — Part 6: Additional specific safety requirements and test methods for Class D devices
• Effective Date: 06-Jun-2022

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 17215-2
First edition
2014-04-15
Road vehicles — Video communication
interface for cameras (VCIC) —
Part 2:
Service discovery and control
Véhicules routiers — Interface de communication vidéo pour caméras
(ICVC)
Reference number
ISO 17215-2:2014(E)
©
ISO 2014

---------------------- Page: 1 ----------------------
ISO 17215-2:2014(E)

COPYRIGHT PROTECTED DOCUMENT
© 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 [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO 2014 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 17215-2:2014(E)

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, and abbreviated terms . 2
3.1 Terms and definitions . 2
3.2 Abbreviated terms . 4
4 Conventions . 4
5 Overview . 4
5.1 General . 4
5.2 Document overview and structure . 4
5.3 Open Systems Interconnection (OSI) model . 4
5.4 Document reference according to OSI model . 5
6 SOME/IP . 6
6.1 General . 6
6.2 Header . 7
6.3 Wire format .10
6.4 Parameter serialization .12
7 Service discovery protocol specification .17
7.1 General .17
7.2 Definitions .17
7.3 General requirements .17
7.4 Service discovery ECU-internal interface .19
7.5 Packet format .19
8 Runtime behaviour .30
8.1 General .30
8.2 SD communication .31
8.3 RPC communication .38
Bibliography .41
© ISO 2014 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO 17215-2:2014(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 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, Electric
and electronic equipment.
ISO 17215 consists of the following parts, under the general title Road vehicles — Video communication
interface for cameras (VCIC):
— Part 1: General information and use case definition
— Part 2: Service discovery and control
— Part 3: Camera message dictionary
— Part 4: Implementation of communication requirements
iv © ISO 2014 – All rights reserved

---------------------- Page: 4 ----------------------
ISO 17215-2:2014(E)

Introduction
Driver assistance systems are more and more common in road vehicles. From the beginning, cameras
were part of this trend. Analogue cameras were used in the beginning, because of lower complexity of
the first systems. With increasing demand for more advanced functionality, digital image processing has
been introduced. So-called one box design cameras (combining a digital image sensor and a processing
unit) appeared in the vehicles.
Currently, the market demands such systems with multiple functions. Even different viewing directions
are in use. It seems to be common sense that 6 up to 12 cameras in a single vehicle will be seen in the
next future. Out of this and the limitation in size, power consumption, etc. it will lead to designs where
the cameras are separated from the processing unit. Therefore, a high performance digital interface
between camera and processing unit is necessary.
This International Standard has been established in order to define the use cases, the communication
protocol, and the physical layer requirements of a video communication interface for cameras which
covers the needs of driver assistance applications.
The video communication interface for cameras
— incorporates the needs of the whole life cycle of an automotive grade digital camera,
— utilizes existing standards to define a long-term stable state-of-art video communication interface
for cameras usable for operating and diagnosis purpose,
— can be easily adapted to new physical data link layers including wired and wireless connections by
using existing adaption layers, and
— is compatible with AUTOSAR.
This part of ISO 17215 is related to the general information and use case definition. This is a general
overview document which is not related to the OSI model.
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. When
mapped on this model, the protocol and physical layer requirements specified by this International
Standard, in accordance with Table 1, are broken into following layers:
— application (layer 7), specified in ISO 17215-3;
— presentation layer (layer 6), specified in ISO 17215-2;
— session layer (layer 5), specified in ISO 17215-2;
— transport protocol (layer 4), specified in ISO 17215-4, ISO 13400-2;
— network layer (layer 3), specified in ISO 17215-4, ISO 13400-2;
— data link layer (layer 2), specified in ISO 17215-4, ISO 13400-3;
— physical layer (layer 1), specified in ISO 17215-4, ISO 13400-3.
© ISO 2014 – All rights reserved v

---------------------- Page: 5 ----------------------
ISO 17215-2:2014(E)

Table 1 — Specifications applicable to the OSI layers
Applicability OSI 7 layers Video communication interface for cameras Camera diagnostics
Application (layer 7) ISO 17215-3
Presentation (layer 6) ISO 17215-2
Seven layers
Session (layer 5) ISO 17215-2
according to
ISO 7498-1 Transport (layer 4)
ISO 17215-4 ISO 13400-2
and
Network (layer 3)
Other future interface
ISO/IEC 10731
standards
Data link (layer 2)
ISO 17215-4 ISO 13400-3
Physical (layer 1)
ISO 17215-1 has been established in order to define the use cases for vehicle communication systems
implemented on a video communication interface for cameras; it is an overall document not related to
the OSI model.
ISO 17215-3 covers the application layer implementation of the video communication interface for
cameras; it includes the API.
ISO 17215-2 covers the session and presentation layer implementation of the video communication
interface for cameras.
ISO 17215-4, being the common standard for the OSI layers 1 to 4 for video communication interface for
cameras, complements ISO 13400-2 and ISO 13400-3 and adds the requirement for video transmission
over Ethernet.
ISO 17215-2 and ISO 17215-3 (OSI layer 5 to 7) services have been defined to be independent of the
ISO 17215-4 (OSI layer 1 to 4) implementation. Therefore ISO 17215-4 could be replaced by other future
communication standards.
vi © ISO 2014 – All rights reserved

---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD ISO 17215-2:2014(E)
Road vehicles — Video communication interface for
cameras (VCIC) —
Part 2:
Service discovery and control
1 Scope
This part of ISO 17215 specifies how services can be discovered and controlled. This functionality
is located mainly in layer 5 of the OSI model. Both discovery and control are implemented using the
scalable service oriented middlewire over IP (SOME/IP). Figure 1 shows a diagram of these aspects and
their relation to other parts of this International Standard.
Figure 1 — Overview of ISO 17215
The general terminology defined in ISO 17215-1 is also used in this part of ISO 17215.
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 7498-1, Information processing systems — Open Systems Interconnection — Basic Reference Model:
The Basic Model — Part 1
ISO/IEC 10731, Information technology — Open Systems Interconnection — Basic Reference Model —
Conventions for the definition of OSI services
© ISO 2014 – All rights reserved 1

---------------------- Page: 7 ----------------------
ISO 17215-2:2014(E)

ISO 17215 (all parts), Road vehicles — Video communication interface for cameras (VCIC)
NOTE The keywords shall, should, etc. as defined in [IETF RFC 2119] are used in this part of ISO 17215 to
indicate requirement levels. Capitalization of those keywords is not required.
If an RFC referenced by this part of ISO 17215 has been updated by one or several RFCs, the update is fully
applicable for the purpose of implementing this International Standard. This presumes the additional document
describes an implementation which is compatible with implementation described by document referred to herein.
If one or more errata for an RFC referenced by this part of ISO 17215 have been published, all of these errata
documents are fully applicable for the purpose of implementing this International Standard.
It is assumed that future implementations of this International Standard will use the most recent versions of the
referenced RFCs, but maintain backward compatibility to existing implementations.
3 Terms, definitions, and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 17215-1 and the following
apply.
3.1.1
AUTOSAR
open and standardized automotive software architecture, jointly developed by automobile
manufacturers, suppliers, and tool developers
3.1.2
client
software component that uses a service instance, e.g. by invoking a method
3.1.3
event
fire and forget message invoked on changes or cyclic and sent from server to client
3.1.4
event group
logical grouping of events or notifications within a service in order to ease subscription
3.1.5
field
representation of a remote property which has up to one getter, up to one setter, and up to one notifier
Note 1 to entry: A getter/setter is a method to get/set the value of a field.
3.1.6
fire and forget communication
RPC call that consists only of a request message
3.1.7
interface definition
concrete specification of a service interface (e.g. in IDL or PDU notation)
Note 1 to entry: In the case of ISO 17215, the interface definition is contained in ISO 17215-3.
3.1.8
method
procedure, function, or subroutine that can be called by a client
2 © ISO 2014 – All rights reserved

---------------------- Page: 8 ----------------------
ISO 17215-2:2014(E)

3.1.9
notification
fire and forget message that is sent on defined status changes or periodically by the notifier of an event
or a field
Note 1 to entry: Field messages cannot be distinguished from an event message; therefore, when referring to an
event message, this shall also be true for the messages of notifiers of fields.
3.1.10
parameters
input, output, or input/output arguments of a method
3.1.11
remote procedure call
method call between two processes that is transmitted using messages
3.1.12
request
message from the client to the server invoking a method
3.1.13
request/response communication
RPC that consists of a request and a response
3.1.14
response
message from the server to the client transporting results of a method invocation
3.1.15
server
software component that offers a service instance, e.g. by providing a method
3.1.16
service
logical combination of zero or more methods, zero or more fields, and zero or more events
3.1.17
service instance
instantiation of the service interface, which can exist more than once in the vehicle or on an ECU
3.1.18
service interface
abstract specification of a service including its methods, events, and fields
3.1.19
union
data structure that can dynamically assume different data types (also known as variant)
© ISO 2014 – All rights reserved 3

---------------------- Page: 9 ----------------------
ISO 17215-2:2014(E)

3.2 Abbreviated terms
Term Description
OSI Open Systems Interconnection
PDU Protocol Data Unit
RPC Remote Procedure Call
ECU Electronic Control Unit
IDL Interface Description Language
AUTOSAR AUTomotive Open System ARchitecture
4 Conventions
ISO 17215 is based on the conventions specified in the OSI service conventions (ISO/IEC 10731) as they
apply for physical layer, protocol, network and transport protocol, and diagnostic services.
5 Overview
5.1 General
ISO 17215 has been established in order to implement a standardized video communication interface
for cameras in vehicles.
The focus of ISO 17215 is using existing protocols.
Figure 1 specifies the relation to the other parts of the standard.
Figure 2 specifies the relation of ISO 17215 to existing protocols.
5.2 Document overview and structure
This International Standard consists of a set of four sub-documents, which provide all references and
requirements to support the implementation of a video communication interface for cameras according
to the standard at hand.
— ISO 17215-1:. This part provides an overview of the document set and structure along with use case
definitions and a common set of resources (definitions, references) for use by all subsequent parts.
— ISO 17215-2:. This part specifies the discovery and control of services provided by a VCIC camera.
— ISO 17215-3:. This part specifies the standardized camera messages and data types used by an VCIC
camera (OSI layer 7).
— ISO 17215-4:. This part specifies standardized low-level communication requirements for
implementation of the physical layer, data link layer, network layer, and transport layer (OSI layers
1 to 4).
5.3 Open Systems Interconnection (OSI) model
This International Standard is based on the Open Systems Interconnection (OSI) basic reference model
as specified in ISO/IEC 7498 which structures communication systems into seven layers.
4 © ISO 2014 – All rights reserved

---------------------- Page: 10 ----------------------
ISO 17215-2:2014(E)

All parts of this International Standard are guided by the OSI service conventions as specified in
ISO/IEC 10731 to the extent that they are applicable to diagnostic services. These conventions define
the interaction between the service user and the service provider through service primitives.
The aim of this subclause is to give an overview of the OSI model and show how it has been used as a
guideline for this part of ISO 17215. It also shows how the OSI service conventions have been applied to
this International Standard.
The OSI model structures data communication into seven layers called (from top to bottom) the
application layer (layer 7), presentation layer, session layer, transport layer, network layer, data link
layer, and physical layer (layer 1). A subset of these layers is used in ISO 17215.
The purpose of each layer is to provide services to the layer above. The active parts of each layer,
implemented in software, hardware or any combination of software and hardware, are called entities.
In the OSI model, communication takes place between entities of the same layer in different nodes. Such
communicating entities of the same layer are called peer entities.
The services provided by one layer are available at the Service Access Point (SAP) of that layer. The layer
above can use them by exchanging data parameters.
This International Standard distinguishes between the services provided by a layer to the layer above it
and the protocol used by the layer to send a message between the peer entities of that layer. The reason
for this distinction is to make the services, especially the application layer services and the transport
layer services, reusable also for other types of networks than the video communication interface for
cameras. In this way, the protocol is hidden from the service user and it is possible to change the protocol
if demanded by special system requirements.
5.4 Document reference according to OSI model
Figure 2 illustrates the document references.
© ISO 2014 – All rights reserved 5

---------------------- Page: 11 ----------------------
ISO 17215-2:2014(E)

a
layer 7
layer 6
d
c
layer 5
s p i
f
layer 4
layer 3
f t
layer 2
link
layer 1
Figure 2 — Video communication interface for camera’s document reference according to OSI
model
6 SOME/IP
6.1 General
Service discovery as well as command and control is performed using the Scalable service-Oriented
MiddlewarE over IP. SOME/IP is a lightweight RPC protocol that defines an AUTOSAR-compatible
method for describing interfaces and marshalling data over automotive Ethernet and IP networks. The
basic feature set of the SOME/IP wire format is already supported by AUTOSAR. This allows AUTOSAR
to parse the RPC PDUs and transport the signals to the application.
6 © ISO 2014 – All rights reserved

---------------------- Page: 12 ----------------------
ISO 17215-2:2014(E)

6.2 Header
This subclause defines the header structure.
For interoperability reasons, the header layout shall be identical for all implementations of SOME/IP and
is shown in Figure 3.
— The header-fields are presented in transmission order; i.e. the header-fields on the top left are
transmitted first. In the following sections, the different header-fields and their usage is being
described.
— All RPC header fields shall use network byte order (big endian) [IETF RFC 791].
Figure 3 — General SOME/IP header layout
6.2.1 Message ID [32-bit]
The Message ID is a 32-bit identifier that is used to dispatch the RPC call to the method of an application
and to identify an event.
The assignment of the Message ID is up to the user. The next section describes how to structure the
Message IDs in order to ease the organization of Message IDs.
— The Message ID shall uniquely identify a method or an event and the format of its associated PDUs.
In order to structure the different methods and events, they are clustered into services. Services have
a set of methods and events as well as a Service ID, which is used for exactly one service. Events are in
addition clustered into event groups, which simplify the subscription for multiple events.
— The message ID for RPC calls shall consist of a 16-bit Service ID (high bytes) and a 16-bit Method ID
(low bytes).
— The Service ID and the Method ID shall be defined in the interface specification.
— The highest bit of the Event ID shall always be one.
This scheme allows for up to 65 536 services with up to 32 767 methods and 32767 events each.
— The message ID for events shall consist of a 16-bit Service ID (high bytes) and a 16-bit Notification
ID (low bytes).
— The Eventgroup ID and Event ID shall be specified in the interface specification.
— The highest bit of the Eventgroup ID shall always be one.
© ISO 2014 – All rights reserved 7

---------------------- Page: 13 ----------------------
ISO 17215-2:2014(E)

6.2.2 Length [32-bit]
Length is a field of 32 bits containing the length (in bytes) of the payload, beginning with the Request
ID/Client ID and ending with the end of the SOME/IP message. The length does not include the Message.
6.2.3 Request ID [32-bit]
The Request ID allows a client to differentiate multiple calls to the same method.
— The Request ID shall be unique for a single client and server combination.
— When generating a response message, the server shall copy the Request ID from the request to the
response message. This allows the client to map a response to the issued request even with more
than one request outstanding.
The Request ID needs to be restructured.
— The Request ID shall consist of a 16-bit Client ID (high bytes) and a 16-bit Session ID (low bytes).
The Client ID is the unique identifier for the calling client inside the ECU. The Session ID is a unique
identifier chosen by the client for each call.
— The Client ID within each ECU shall be configured by the manufacturer.
— If no response to a message is expected, e.g. for events or notifications, the Session ID shall be set to
0x0000.
— If response messages are expected the Session ID shall be incremented for each method call within
the same life cycle (starting with 0x0001, also after wrapping).
— The client shall be responsible for invalidating responses to outdated requests if necessary.
6.2.4 Protocol version [8-bit]
Protocol version is an 8-bit field containing the SOME/IP protocol version.
— The protocol version shall be set to 0x01.
6.2.5 Interface major version [8-bit]
Interface major version is an 8-bit field that contains the major version of the service interface. This is
required to catch mismatches in service definitions and allow debugging tools to identify the service
interface used (see ISO 17215-3).
6.2.6 Message type [8-bit]
The message type field is used to differentiate between different types of messages.
— The message type shall be set to one of the values listed in Table 2.
— A REQUEST shall be answered by a RESPONSE if no error occurred.
— A REQUEST shall be answered by an ERROR if errors occurred.
— A REQUEST_NO_RETURN, a NOTIFICATION or any ACK message shall not be answered.
8 © ISO 2014 – All rights reserved

---------------------- Page: 14 ----------------------
ISO 17215-2:2014(E)

Table 2 — SOME/IP Message types
Number Value Description
0x00 REQUEST A request expecting a response (even void)
0x01 REQUEST_NO_RETURN A fire and forget request (client to server)
0x02 NOTIFICATION A notification/event callback expecting no response (server
to client)
(0x40) REQUEST ACK Acknowledgement for REQUEST (optional)
(0x41) REQUEST_NO_RETURN ACK Acknowledgement for REQUEST_NO_RETURN (optional)
(0x42) NOTIFICATION ACK Acknowledgement for NOTIFICATION (optional)
0x80 RESPONSE The response message
0x81 ERROR The response containing an error
(0xC0) RESPONSE ACK Acknowledgement for RESPONSE (optional)
(0xC1) ERROR ACK Acknowledgement for ERROR (optional)
Acknowledgement messages (ACK) may be used in cases where the transport protocol (i.e. UDP) does
not guarantee message delivery.
All ACKs are optional and do not need to be implemented.
6.2.7 Return code [8-bit]
The return code is used to signal whether a request was processed successfully. For simplification of the
header layout, every message transports the field, whether it is applicable or not.
— Response messages (message type 0x80) shall use the return code field to transmit a return code to
the request they answer.
— Error messages (message type 0x81) shall use the return code field to transmit a return code to the
request they answer, but shall not use the return code 0x00.
— Acknowledgement messages shall reuse the return code of the message they acknowledge.
— All other messages shall set the return code field to 0x00.
— The return codes are based on an 8-bit Std_returnType of AUTOSAR. The two most significant bits
are reserved and shall be set to zero (0). The receiver of a return code shall ignore the values of the
two most significant bits.
— The currently defined return codes are listed in Table 3 and shall be implemented as described.
Table 3 — SOME/IP return codes
ID Name Description
0x00 E_OK No error occurred
0x01 E_NOT_OK An unspec
...