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
• Start Date: 20-Mar-2025
• Completion Date: 13-Dec-2025

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

Overview

ISO 17215-2:2014 - part of the Video Communication Interface for Cameras (VCIC) family - specifies service discovery and control for automotive camera systems. Focused mainly on the OSI session (layer 5) and presentation (layer 6) responsibilities, this part defines how camera-related services are advertised, discovered, invoked and managed across vehicle networks. Discovery and control are implemented using SOME/IP (Scalable service oriented middlewire over IP). ISO 17215-2 uses the general terminology established in ISO 17215-1 and is designed to integrate with AUTOSAR-compatible architectures.

Key topics and technical requirements

• Service discovery protocol: Defines how service instances (e.g., camera streams, diagnostics or configuration services) are advertised and discovered on the vehicle IP network using SOME/IP-based Service Discovery (SD) mechanisms.
• Control and RPC behaviour: Specifies remote procedure call (RPC) semantics for invoking methods, request/response and fire-and-forget patterns, and how parameters and responses are carried.
• Presentation and serialization: Details parameter serialization, wire format and header conventions required to transport service messages reliably and interoperably.
• Packet format and headers: Describes SOME/IP header, PDU/wire format and payload structures used for service discovery and control messages.
• Runtime behaviour: Covers ECU-internal interfaces, SD communication flows, RPC communication flows and expected state transitions during service registration, subscription and notification.
• Terminology and conventions: Reuses OSI model conventions (ISO 7498-1, ISO/IEC 10731) and aligns with the broader ISO 17215 set for consistent definitions of services, methods, events, fields and instances.

Practical applications and who uses it

ISO 17215-2 is intended for anyone building or integrating automotive camera systems and middleware for advanced driver assistance and vehicle perception tasks. Typical users include:

• OEM system architects and vehicle integration teams designing multi-camera systems (e.g., 6–12 cameras per vehicle scenarios).
• Tier‑1 suppliers and camera module manufacturers implementing camera ECUs and middleware.
• Firmware, middleware and software developers implementing SOME/IP-based discovery, RPC, serialization and control logic.
• Test, validation and diagnostics engineers who verify service registration, discovery, subscription and runtime message flows.
• Architects ensuring AUTOSAR compatibility and future-proof integration with physical/data link layers defined in ISO 17215-4 or alternate transports.

Related standards

• ISO 17215-1 (general information and use cases)
• ISO 17215-3 (application layer / camera message dictionary)
• ISO 17215-4 (layers 1–4: transport, network, data link, physical)
• ISO 7498-1 and ISO/IEC 10731 (OSI reference model and service conventions)
• ISO 13400-2 / ISO 13400-3 (related transport and data‑link references)

Keywords: ISO 17215-2, VCIC, video communication interface for cameras, SOME/IP, service discovery, service control, automotive camera interface, OSI layer 5, AUTOSAR, ECU, RPC, parameter serialization.

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 2014
© 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

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
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

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.
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

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 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

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)
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

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.
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

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.
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

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 unspecified error occurred
0x02 E_UNKNOWN_SERVICE The requested Service ID is unknown
0x03 E_UNKNOWN_METHOD The requested Method ID is unknown. Service ID is
known.
0x04 E_NOT_READY Service ID and Method ID are known. Application not
running.
0x05 E_NOT_REACHABLE System running the service is not reachable
a
These errors will be specified in future versions of this part of ISO 17215.
b
These error codes are specified by the interface specification for each service.
Table 3 (continued)
ID Name Description
0x06 E_TIMEOUT A timeout occurred
0x07 E_WRONG_PROTOCOL_VERSION Version of SOME/IP protocol not supported
0x08 E_WRONG_INTERFACE_VERSION Interface version mismatch
0x09 E_MALFORMED_MESSAGE Deserialization error (i.e. length or type incorrect)
a
0x10 - 0x1F RESERVED Reserved for generic SOME/IP errors
b
0x20 - 0x3F RESERVED Reserved for application-specific errors
a
These errors will be specified in future versions of this part of ISO 17215.
b
These error codes are specified by the interface specification for each service.
6.2.8 Payload [variable size]
In the payload field, the parameters are carried. The mechanism for serialization of the parameters is
specified in the following section.
6.3 Wire format
The wire format describes data representation in PDUs transported over an IP-based automotive in-
vehicle network.
6.3.1 Transport
SOME/IP directly supports the two most common transport protocols of the Internet: User Datagram
Protocol (UDP) and Transmission Control Protocol (TCP). While UDP is a very lean transport protocol
supporting only the most important features (multiplexing and error detecting using a checksum), TCP
adds additional features for achieving reliable communication.
— The port numbers for SOME/IP services shall be specified by the OEM.
— UDP should be used if there are hard latency requirements (<100 ms) in case of errors.
— TCP should be used only if large chunks of data need to be transported (>>1 kb) and no hard latency
requirements in the case of errors exist.
— The choice of the transport protocol shall be documented for every method in the interface
specification.
— Methods, events, and fields should not support the use of more than one transport protocol.
In combination with regular Ethernet, IPv4 and UDP can transport packets with up to 1 472 bytes of
data without fragmentation. The IPv6 header requires additional 20 bytes. Fragmentation shall be
avoided especially in small systems, so the SOME/IP header and payload should be of limited length. The
possible usage of security protocols further limits the maximum size of SOME/IP messages. TCP allows
segmented payloads, but AUTOSAR currently limits messages to 4 095 bytes.
Other transport mechanisms (Network File System, IEEE 1722, and so forth) can also be used when they
are more suitable for the use case. In this case, SOME/IP is only used to transport a file handle or similar.
6.3.1.1 UDP binding
Many applications inside the vehicle require short timeouts to enable fast reaction. These requirements
are better met using UDP, because the application itself can handle the unlikely case of errors in a flexible
manner. For example, in use cases with cyclic data, it is often the best approach to just wait for the next
10 © ISO 2014 – All rights reserved

data transmission instead of trying to repair the last one. The major disadvantage of UDP is that it does
not handle segmentation, and thus, can only transport small chunks of data.
— SOME/IP messages over UDP can use up to 1 416 bytes for the SOME/IP header and payload.
— The header format allows transporting more than one SOME/IP message in a single UDP packet.
The SOME/IP implementation shall identify the end of a SOME/IP message by means of the SOME/IP
length field. Based on the UDP lengths field, SOME/IP shall determine if there are additional SOME/IP
messages in the UDP packet. The SOME/IP messages can be unaligned.
— Each SOME/IP payload shall have its own SOME/IP header.
— If specified by the interface definition, SOME/IP shall send an acknowledgement message before the
result of a long-running operation becomes available (processing acknowledgement).
6.3.1.2 TCP binding
The TCP binding of SOME/IP is heavily based on the UDP binding. In contrast to the UDP binding,
the TCP binding allows much larger SOME/IP messages and the batch transport of a large number of
SOME/IP messages (pipelining). TCP cannot only handle bit errors, but also packet segmentation, loss,
duplication, reordering, and network congestion.
— SOME/IP messages over TCP, including the SOME/IP header, shall not exceed 4 095 Bytes.
— Every SOME/IP payload shall have its own SOME/IP header.
— In order to lower latency and reaction time, Nagle’s algorithm should be turned off (TCP_NODELAY).
— When the TCP connection is lost, outstanding requests shall be handled as timeouts. Otherwise,
TCP guarantees packet delivery, so additional measures for robustness are not necessary.
— The TCP connection shall be opened by the client, when the first method call is transport or the
client tries to receive the first notifications depending on the first occurrence.
— In order to allow resynchronization to SOME/IP over TCP in testing and integration scenarios, the
SOME/IP magic cookie message (Figure 4) shall be used between SOME/IP messages over TCP.
— The magic cookie message uses a Service ID of 0xFFFF and a Method ID of 0x0000 (client to server)
respectively 0x8000 (server to client).
— The magic cookie message has a length of 8 bytes, a fixed Client ID of 0xDEAD and a fixed Session ID
of 0xBEEF. The protocol version is 0x01, the interface version 0x01, the message type 0x01 (client to
server) respectively 0x02 (server to client). The return code is 0x00.
— Before the first SOME/IP message is transported in a TCP segment, the SOME/IP magic cookie
message shall be included.
— The implementation shall only include up to one SOME/IP magic cookie message per TCP segment.
— If the implementation has no appropriate access to the message segmentation mechanisms and
therefore cannot fulfil the two previous requirements, the implementation shall include SOME/IP
magic cookie messages once every 10 s in the TCP connection as long as messages are transmitted
over this TCP connection.
Figure 4 — SOME/IP magic cookie
6.3.2 Mapping of IP addresses and ports
For response and error messages, the IP addresses and port number of the transport protocol shall
match the request message. In particular, this means:
— The source IP address of the response message shall be the destination IP address of the
corresponding request message.
— The destination IP address of the response message shall be the source IP address of the
corresponding request message.
— The source port of the response message shall be the destination port of the corresponding request
message.
— The destination port of the response message shall be the source port of the corresponding request
message.
6.4 Parameter serialization
An important aspect of the serialization process is the memory alignment of the parameters. This means
that the storage address of a data type should be an integer multiple of its size in bytes, e.g. a float32
parameter should be placed at an offset divisible by four.
— The serialization shall not try to automatically align parameters, but shall align them as specified in
the interface specification.
— If a SOME/IP implementation encounters an interface specification that leads to a PDU that is not
correctly aligned (e.g. because of an unaligned structure), a SOME/IP implementation shall warn
about a misaligned structure but shall not fail in generating the code.
— The parameters shall be marked as IN, OUT, or INOUT in the interface specification.
12 © ISO 2014 – All rights reserved

— For messages from client to server, OUT parameters shall be skipped in the serialization/deserialization.
— For messages from server to client, IN parameters shall be skipped in the serialization/deserialization.
— The byte order for each parameter shall be specified by the interface definition. Whenever possible,
network byte order (big endian) should be used.
6.4.1 Basic data types
The following basic data types shall be supported:
Table 4 — SOME/IP data types
Size
Type Description Remark
[bit]
boolean TRUE/FALSE value 8 FALSE (0), TRUE (1)
uint8 unsigned integer 8
uint16 unsigned integer 16
uint32 unsigned integer 32
sint8 signed integer 8
sint16 signed integer 16
sint32 signed integer 32
float32 floating point number 32 IEEE 754 binary32 (single precision)
float64 floating point number 64 IEEE 754 binary64 (double precision)
6.4.2 Structured data types
The serialization of a structure is based on its in-memory layout. Especially for structures it is important
to consider the memory alignment. Insert padding elements in the interface definition if needed for
alignment. An example is given in Figure 5.
— The interface specification can add a length field of 8 bits, 16 bits, or 32 bits in front of the structure.
— The length field describes the number of bytes which are transmitted. If the size of the structure as
specified in the interface is smaller than the given length, the additional bytes at the end shall be
skipped in the deserialization. This is to ease the migration of interfaces.
— If the size of the length field is not specified, a length of 0 has to be assumed and no length field is in
the message.
Figure 5 — Serialization of structures
6.4.3 Arrays
Arrays are simply seen as repeated elements. Multidimensional arrays are supported. SOME/IP supports
both fixed-size and dynamic-size arrays. Fixed-size arrays are less flexible, but can be more efficient and
have better support in earlier versions of AUTOSAR.
NOTE The serialization of multidimensional arrays shall follow the in-memory layout of multidimensional
arrays in the C programming language (row-major order).
6.4.3.1 Fixed-size arrays
The size (in bytes) of fixed-size arrays shall be defined by the interface definition. The example layout of
a two-dimensional array is illustrated in Figure 6.
Figure 6 — Fixed-size multidimensional array memory layout
6.4.3.2 Dynamic-size arrays
The layout of arrays with dynamic length is the same as for fixed-length arrays, with additional explicit
length fields.
— To determine the size of the array, the serialization shall add a length field of 8 bits, 16 bits, or 32 bits
in front of the data, which counts the total bytes of the array.
— The length shall not include the size of the length field.
— Each row shall have its own length field.
— If not specified, otherwise, in the interface specification, the size of the length field is 32 bits.
— The interface definition shall define the maximum length of each dimension to allow static buffer
size allocation.
Thus, when transporting an array with zero elements, the length is set to zero. The memory layout of
dynamic arrays is shown in Figure 7.
14 © ISO 2014 – All rights reserved

Figure 7 — Dynamic-size multidimensional array memory layout
6.4.3.2.1 Optional fields
Optional fields shall be specified in the interface definition as a dynamic-size array. Its length will then
be either 0 or 1, depending on whether the parameter is present or not.
6.4.3.2.2 Map/Dictionary
Maps or dictionaries shall be described as a dynamic-size array of key-value-pair structures. An example
of this important data structure can be seen in Table 5.
Table 5 — Serialized dictionary example
Length = 12 bytes
key0 [uint16] value0 [uint16]
key1 [uint16] value1 [uint16]
key2 [uint16] value2 [uint16]
6.4.4 Strings
Strings are simply one-dimensional byte arrays in UTF-8 encoding. Since this encoding uses a variable
number of bytes per character, the length of a string in bytes is different from the number of characters.
In the worst case, three times the number of characters plus 4 bytes for the termination with a “\0” and
the Byte Order Mark (BOM) might be needed for UTF-8 strings. All strings shall start with a BOM.
6.4.4.1 Strings (fixed length)
The following rules apply for strings with fixed length.
— Strings shall be encoded using UTF-8, UTF-16 BE, or UTF-16 LE and terminated with a NULL
character.
— The length of the string (including the terminator) in bytes shall be specified in the interface
definition.
— Unused space shall be filled with NULL characters.
6.4.4.2 Strings (dynamic length)
The following requirements apply for strings with dynamic length.
— Dynamic-length strings shall start with a length field.
— The size of the length field shall be either 8 bits, 16 bits, or 32 bits. Fixed-length strings might be
seen as having a 0-bit length field.
— If not specified, otherwise, in the interface specification, the size of the length field is 32 bits.
— Strings shall be encoded using UTF-8, UTF-16 BE, or UTF-16 LE and shall be terminated with a NULL
character.
— The length field shall be set to the number of bytes occupied by the string (including the terminator).
— The maximum length of the string (including the terminator) in bytes shall be specified in the
interface definition.
6.4.5 Union/Variant
A union (also called variant) is a parameter whose contents can be interpreted in different data formats.
— The serialization layout of unions shall consist of a length field and a type field, followed by the
actual storage space.
— The length field shall define the size of the parameter storage space, including padding, in bytes and
does not include the size of the length field and type field.
— The type field shall describe the type of the parameter. Possible values of the type field are defined
by the interface specification for each union separately. The types are encoded as in the interface
specification in ascending order starting with 1. The 0 is reserved for the NULL type, i.e. an empty
union. The usage of NULL shall be allowed by the interface definition.
— The size of the length field shall be defined by the interface specification and shall be 32 bits, 16 bits,
8 bits, or 0 bit.
— The value of the length field shall be defined by the interface specification. The value shall be high
enough to accommodate the largest possible type.
— A length field of 0 bit means th
...