Road vehicles -- Video communication interface for cameras (VCIC)

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)

General Information

Status
Published
Publication Date
05-May-2014
Current Stage
6060 - International Standard published
Start Date
28-Mar-2014
Completion Date
06-May-2014
Ref Project

Buy Standard

Standard
ISO 17215-2:2014 - Road vehicles -- Video communication interface for cameras (VCIC)
English language
41 pages
sale 15% off
Preview
sale 15% off
Preview

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 copyright@iso.org
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)
layer 7
layer 6
layer 5
s p i
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
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.