Autosar Prs Someipprotocol

SOME/IP Protocol Specification
AUTOSAR FO Release 1.0.0
Document Title SOME/IP Protocol Specification

Document Owner AUTOSAR
Document Responsibility AUTOSAR
Document Identification No 696
Document Classification Standard
Document Status Final

Part of AUTOSAR Standard Foundation
Part of Standard Release 1.0.0
Document Change History

Date Release Changed by Description
AUTOSAR
2016-11-30 1.0.0 Release Initial Release
Management
1 of 50 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

— AUTOSAR CONFIDENTIAL —
Disclaimer
This specification and the material contained in it, as released by AUTOSAR, is for the
purpose of information only. AUTOSAR and the companies that have contributed to it
shall not be liable for any use of the specification.
The material contained in this specification is protected by copyright and other types of
Intellectual Property Rights. The commercial exploitation of the material contained in
this specification requires a license to such Intellectual Property Rights.
This specification may be utilized or reproduced without any modification, in any form
or by any means, for informational purposes only. For any other purpose, no part of
the specification may be utilized or reproduced, in any form or by any means, without
permission in writing from the publisher.
The AUTOSAR specifications have been developed for automotive applications only.
They have neither been developed, nor tested for non-automotive applications.
The word AUTOSAR and the AUTOSAR logo are registered trademarks.
Advice for users
AUTOSAR specifications may contain exemplary items (exemplary reference models,

"use cases", and/or references to exemplary technical solutions, devices, processes or
software).
Any such exemplary items are contained in the specifications for illustration purposes
only, and they themselves are not part of the AUTOSAR Standard. Neither their pres-
ence in such specifications, nor any later documentation of AUTOSAR conformance of
products actually implementing such exemplary items, imply that intellectual property
rights covering such exemplary items are licensed under the same rules as applicable
to the AUTOSAR Standard.

Table of Contents
1 Introduction and overview 5
1.1 Protocol purpose and objectives . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Applicability of the protocol . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Constraints and assumptions . . . . . . . . . . . . . . . . . . 5
1.2.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Document Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Protocol Requirements 8
2.1 Requirements Traceability . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Acronyms and Abbreviations 13
4 Protocol specification 14
4.1 Specification of SOME/IP on wire-format (Serialization) . . . . . . . . . 14
4.1.1 Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.1.1 Message ID [32 Bit] . . . . . . . . . . . . . . . . . . 15
4.1.1.2 Length [32 Bit] . . . . . . . . . . . . . . . . . . . . . 15
4.1.1.3 Request ID [32 Bit] . . . . . . . . . . . . . . . . . . . 16
4.1.1.4 Protocol Version [8 Bit] . . . . . . . . . . . . . . . . . 17
4.1.1.5 Interface Version [8 Bit] . . . . . . . . . . . . . . . . 17
4.1.1.6 Message Type [8 Bit] . . . . . . . . . . . . . . . . . . 17
4.1.1.7 Return Code [8 Bit] . . . . . . . . . . . . . . . . . . . 18
4.1.1.8 Payload [variable size] . . . . . . . . . . . . . . . . . 18
4.1.2 Event, Field and Eventgroup . . . . . . . . . . . . . . . . . . 19
4.1.3 Endianess . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.4 Serialization of Data Structures . . . . . . . . . . . . . . . . . 19
4.1.4.1 Basic Datatypes . . . . . . . . . . . . . . . . . . . . 20
4.1.4.2 Structured Datatypes (structs) . . . . . . . . . . . . . 21
4.1.4.3 Strings . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.4.4 Arrays (fixed length) . . . . . . . . . . . . . . . . . . 23
4.1.4.5 Dynamic Length Arrays . . . . . . . . . . . . . . . . 25
4.1.4.6 Enumeration . . . . . . . . . . . . . . . . . . . . . . 26
4.1.4.7 Bitfield . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.4.8 Union / Variant . . . . . . . . . . . . . . . . . . . . . 27
4.2 Specification of SOME/IP Protocol . . . . . . . . . . . . . . . . . . . . 28
4.2.1 Transport Protocol Bindings . . . . . . . . . . . . . . . . . . . 29
4.2.1.1 UDP Binding . . . . . . . . . . . . . . . . . . . . . . 29
4.2.1.2 TCP Binding . . . . . . . . . . . . . . . . . . . . . . 29
4.2.1.3 Multiple Service-Instances . . . . . . . . . . . . . . . 31
4.2.1.4 Transporting large SOME/IP messages of UDP
(SOME/IP-TP) . . . . . . . . . . . . . . . . . . . . . 32
4.2.2 Request/Response Communication . . . . . . . . . . . . . . 38
4.2.3 Fire&Forget Communication . . . . . . . . . . . . . . . . . . 39

4.2.4 Notification Events . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2.4.1 Strategy for sending notifications . . . . . . . . . . . 41
4.2.5 Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.6 Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.6.1 Return Code . . . . . . . . . . . . . . . . . . . . . . 42
4.2.6.2 Error Message . . . . . . . . . . . . . . . . . . . . . 43
4.2.6.3 Error Processing Overview . . . . . . . . . . . . . . 44
4.2.6.4 Communication Errors and Handling of Communica-
tion Errors . . . . . . . . . . . . . . . . . . . . . . . . 46
5 Configuration Parameters 47
6 Protocol usage and guidelines 48

6.1 Choosing the transport protocol . . . . . . . . . . . . . . . . . . . . . . 48
6.2 Transporting CAN and FlexRay Frames . . . . . . . . . . . . . . . . . . 48
6.3 Insert Padding for structs . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7 References 50

1 Introduction and overview

This protocol specification specifies the format, message sequences and seman-
tics of the AUTOSAR Protocol "Scalable service-Oriented MiddlewarE over IP
(SOME/IP)".
SOME/IP is an automotive/embedded communication protocol which supports remote
procedure calls, event notifications and the underlying serialization/wire format. The
only valid abbreviation is SOME/IP. Other abbreviations (e.g. Some/IP) are wrong and
shall not be used.
1.1 Protocol purpose and objectives

The basic motivation to specify "Yet another RPC-Mechanism" instead of using an
existing infrastructure/technology is the goal to have a technology that:
• Fulfills the hard requirements regarding resource consumption in an embedded
world
• Is compatible through as many use-cases and communication partners as possi-
ble
• compatible with AUTOSAR at least on the wire-format level; i.e. can commu-
nicate with PDUs AUTOSAR can receive and send without modification to the
AUTOSAR standard. The mappings within AUTOSAR shall be chosen according
to the SOME/IP specification.
• Provides the features required by automotive use-cases
• Is scalable from tiny to large platforms
1.2 Applicability of the protocol

SOME/IP shall be implemented on different operating system (i.e. AUTOSAR, GENIVI,
and OSEK) and even embedded devices without operating system. SOME/IP shall be
used for inter-ECU Client/Server Serialization. An implementation of SOME/IP allows
AUTOSAR to parse the RPC PDUs and transport the signals to the application.
1.2.1 Constraints and assumptions
This document specifies the SOME/IP protocol on network level. It was created during
elaboration of the AUTOSAR Foundation Standard 1.0.0 which took place in parallel
to the development of the AUTOSAR Classic Standard 4.3.0. It already reflects all
changes implied to SOME/IP by the work which was done for AUTOSAR Classic

Standard 4.3.0.
Therefore the SOME/IP protocol specified here is not fully backward-compatible to the
SOME/IP protocol used in AUTOSAR Classic Standard 4.2.2. The most important
differences are:
• Unicode strings are always preceded by a BOM (see Chapter 4.1.4.3)
The older version was not consistent with respect to the usage of BOMs. The cur-
rent version of SOME/IP mandates that every unicode string starts with a BOM.
Everything else is no string but an array of uint8, uint16 or uint32 elements.
• Message Types have been changed (see [PRS_SOMEIP_00055] and Table 4.4):
The types for acknowledgements (REQUEST_ACK, RE-
QUEST_NO_RETURN_ACK, NOTIFICATION_ACK, RESPONSE_ACK and
ERROR_ACK) were completely removed because they were defined but never
used in the protocol.
• Segmentation functionality (SOME/IP-TP) was introduced (see Chapter 4.2.1.4):
Large data (>1400 Bytes) can now be transferred via UDP. SOME/IP-TP can
segment larger data into small chunks which can be transferred via UDP and
reassembled at receiver side.
1.2.2 Limitations
This document gives a holistic overview over SOME/IP but doesn’t state any require-
ments towards any implementation of BSW modules.
Please be aware that not all parts of SOME/IP may be implemented in AUTOSAR.
1.3 Dependencies
There are no dependencides to AUTOSAR SWS modules.
1.4 Document Structure

The SOME/IP PRS will describe the following two aspects of SOME/IP.
Specification of SOME/IP on wire-format (Serialization)
• Structure of Header Format
• How the different data types are serialized as per SOME/IP
Specification of Protocol for Event and RPC-based communication
• Transport Protocol

• Rules that govern the RPC for SOME/IP

2 Protocol Requirements
2.1 Requirements Traceability
Feature Description Satisfied by

[RS_SOMEIP_00004] SOME/IP protocol shall support [PRS_SOMEIP_00925]
event communication [PRS_SOMEIP_00926]
uni-directional RPC communication [PRS_SOMEIP_00924]
bi-directional RPC communication [PRS_SOMEIP_00921]
[PRS_SOMEIP_00922]
[PRS_SOMEIP_00923]
[PRS_SOMEIP_00927]
[PRS_SOMEIP_00928]
error handling of RPC [PRS_SOMEIP_00188]
communication [PRS_SOMEIP_00189]
[PRS_SOMEIP_00190]
[PRS_SOMEIP_00191]
[PRS_SOMEIP_00195]
[PRS_SOMEIP_00537]
[PRS_SOMEIP_00539]
[PRS_SOMEIP_00576]
[PRS_SOMEIP_00614]
[PRS_SOMEIP_00901]
[PRS_SOMEIP_00902]
[PRS_SOMEIP_00903]
[PRS_SOMEIP_00904]
[PRS_SOMEIP_00905]
[PRS_SOMEIP_00910]
field communication [PRS_SOMEIP_00180]
[PRS_SOMEIP_00181]
[PRS_SOMEIP_00182]
[PRS_SOMEIP_00183]
[PRS_SOMEIP_00909]


different transport protocols [PRS_SOMEIP_00138]
underneath [PRS_SOMEIP_00139]
[PRS_SOMEIP_00140]
[PRS_SOMEIP_00141]
[PRS_SOMEIP_00142]
[PRS_SOMEIP_00154]
[PRS_SOMEIP_00160]
[PRS_SOMEIP_00535]
[PRS_SOMEIP_00706]
[PRS_SOMEIP_00707]
[PRS_SOMEIP_00708]
[PRS_SOMEIP_00709]
[PRS_SOMEIP_00710]
[PRS_SOMEIP_00711]
[PRS_SOMEIP_00720]
[PRS_SOMEIP_00721]
[PRS_SOMEIP_00722]
[PRS_SOMEIP_00723]
[PRS_SOMEIP_00724]
[PRS_SOMEIP_00725]
[PRS_SOMEIP_00726]
[PRS_SOMEIP_00727]
[PRS_SOMEIP_00728]
[PRS_SOMEIP_00729]
[PRS_SOMEIP_00730]
[PRS_SOMEIP_00731]
[PRS_SOMEIP_00732]
[PRS_SOMEIP_00733]
[PRS_SOMEIP_00734]
[PRS_SOMEIP_00735]
[PRS_SOMEIP_00736]
[PRS_SOMEIP_00738]
[PRS_SOMEIP_00740]
[PRS_SOMEIP_00741]
[PRS_SOMEIP_00742]
[PRS_SOMEIP_00743]
[PRS_SOMEIP_00744]
[PRS_SOMEIP_00745]
[PRS_SOMEIP_00746]
[PRS_SOMEIP_00747]
[PRS_SOMEIP_00748]
[PRS_SOMEIP_00749]
[PRS_SOMEIP_00750]
[PRS_SOMEIP_00751]
[PRS_SOMEIP_00752]
[PRS_SOMEIP_00753]
[PRS_SOMEIP_00754]


messages of different lengths [PRS_SOMEIP_00163]
[PRS_SOMEIP_00720]
[PRS_SOMEIP_00721]
[PRS_SOMEIP_00722]
[PRS_SOMEIP_00723]
[PRS_SOMEIP_00724]
[PRS_SOMEIP_00725]
[PRS_SOMEIP_00726]
[PRS_SOMEIP_00727]
[PRS_SOMEIP_00728]
[PRS_SOMEIP_00729]
[PRS_SOMEIP_00730]
[PRS_SOMEIP_00731]
[PRS_SOMEIP_00732]
[PRS_SOMEIP_00733]
[PRS_SOMEIP_00734]
[PRS_SOMEIP_00735]
[PRS_SOMEIP_00736]
[PRS_SOMEIP_00738]
[PRS_SOMEIP_00740]
[PRS_SOMEIP_00741]
[PRS_SOMEIP_00742]
[PRS_SOMEIP_00743]
[PRS_SOMEIP_00744]
[PRS_SOMEIP_00745]
[PRS_SOMEIP_00746]
[PRS_SOMEIP_00747]
[PRS_SOMEIP_00748]
[PRS_SOMEIP_00749]
[PRS_SOMEIP_00750]
[PRS_SOMEIP_00751]
[PRS_SOMEIP_00752]
[PRS_SOMEIP_00753]
[PRS_SOMEIP_00754]
[RS_SOMEIP_00026] SOME/IP protocol shall define the [PRS_SOMEIP_00368]
endianness of header and payload [PRS_SOMEIP_00369]

[RS_SOMEIP_00027] SOME/IP protocol shall define the [PRS_SOMEIP_00030]

header layout of messages [PRS_SOMEIP_00031]
[PRS_SOMEIP_00034]
[PRS_SOMEIP_00035]
[PRS_SOMEIP_00038]
[PRS_SOMEIP_00040]
[PRS_SOMEIP_00042]
[PRS_SOMEIP_00043]
[PRS_SOMEIP_00044]
[PRS_SOMEIP_00046]
[PRS_SOMEIP_00052]
[PRS_SOMEIP_00053]
[PRS_SOMEIP_00055]
[PRS_SOMEIP_00058]
[PRS_SOMEIP_00365]
[PRS_SOMEIP_00366]
[PRS_SOMEIP_00367]
[PRS_SOMEIP_00521]
[PRS_SOMEIP_00533]
[PRS_SOMEIP_00701]
[PRS_SOMEIP_00702]
[PRS_SOMEIP_00703]
[PRS_SOMEIP_00704]
[PRS_SOMEIP_00739]
[RS_SOMEIP_00028] SOME/IP protocol shall specify the [PRS_SOMEIP_00063]
serialization algorithm for data [PRS_SOMEIP_00569]
[PRS_SOMEIP_00611]
[PRS_SOMEIP_00612]
[PRS_SOMEIP_00613]
transporting integer data types [PRS_SOMEIP_00615]
transporting boolean data type [PRS_SOMEIP_00615]
transporting float data types [PRS_SOMEIP_00615]
transporting structured data types [PRS_SOMEIP_00079]
[PRS_SOMEIP_00300]
[PRS_SOMEIP_00370]
[PRS_SOMEIP_00371]
[PRS_SOMEIP_00705]
[PRS_SOMEIP_00712]
[PRS_SOMEIP_00900]


transporting union data types [PRS_SOMEIP_00119]
[PRS_SOMEIP_00121]
[PRS_SOMEIP_00122]
[PRS_SOMEIP_00123]
[PRS_SOMEIP_00126]
[PRS_SOMEIP_00127]
[PRS_SOMEIP_00129]
[PRS_SOMEIP_00130]
[PRS_SOMEIP_00906]
[PRS_SOMEIP_00907]
[PRS_SOMEIP_00908]
[PRS_SOMEIP_00915]
[PRS_SOMEIP_00916]
transporting one-dimensional and [PRS_SOMEIP_00101]
multi-dimensional array data types
transporting array data types with a [PRS_SOMEIP_00101]
fixed length [PRS_SOMEIP_00917]
[PRS_SOMEIP_00918]
transporting array data types with [PRS_SOMEIP_00114]
flexible length [PRS_SOMEIP_00375]
[PRS_SOMEIP_00376]
[PRS_SOMEIP_00377]
[PRS_SOMEIP_00919]
transporting string types with a fixed [PRS_SOMEIP_00085]
length [PRS_SOMEIP_00086]
[PRS_SOMEIP_00087]
[PRS_SOMEIP_00372]
[PRS_SOMEIP_00373]
[PRS_SOMEIP_00374]
[PRS_SOMEIP_00911]
[PRS_SOMEIP_00912]
[PRS_SOMEIP_00913]
[PRS_SOMEIP_00914]
transporting string data types with [PRS_SOMEIP_00090]
flexible length [PRS_SOMEIP_00091]
[PRS_SOMEIP_00092]
[PRS_SOMEIP_00093]
[PRS_SOMEIP_00094]
[PRS_SOMEIP_00095]
[RS_SOMEIP_00051] SOME/IP protocol shall provide [PRS_SOMEIP_00367]
support for segmented transmission
of large data

3 Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the SOME/IP
specification that are not included in the [1, AUTOSAR glossary].
Abbreviation / Acronym: Description:

A method, procedure, function, or subroutine that is called/in-
Method
voked.
Parameters input, output, or input/output arguments of a method or an event
A method call from one ECU to another that is transmitted using
Remote Procedure Call (RPC)
messages
Request a message of the client to the server invoking a method
a message of the server to the client transporting results of a
Response
method invocation
Request/Response communica-
a RPC that consists of request and response
tion
A uni-directional data transmission that is only invoked on
Event changes or cyclically and is sent from the producer of data to
the consumers.
A field does represent a status and thus has an valid value at all
Field
times on which getter, setter and notifier act upon.
Notification Event An event message of the notifier of a field.
Getter A Request/Response call that allows read access to a field.
Setter A Request/Response call that allows write access to a field.
Sends out event message with a new value on change of the
Notifier
value of the field.
A logical combination of zero or more methods, zero or more
Service
events, and zero or more fields.
the formal specification of the service including its methods,
Service Interface
events, and fields
A logical grouping of events and notification events of fields inside
Eventgroup
a service in order to allow subscription
Implementation of a service, which can exist more than once in
Service Instance
the vehicle and more than once on an ECU
The ECU offering a service instance shall be called server in the
Server
context of this service instance.
The ECU using the service instance of a server shall be called
Client
client in the context of this service instance.
Fire and Forget Requests without response message are called fire&forget.
A data structure that dynamically assumes different data types.
Union
Table 3.1: Acronyms and Abbreviations

4 Protocol specification
SOME/IP provides service oriented communication over a network. It is based on
service definitions that list the functionality that the service provides. A service can
consist of combinations of zero or multiple events, methods and fields.
Events provide data that are sent cyclically or on change from the provider to the sub-
scriber.
Methods provide the possibility to the sbscriber to issue remote procedure calls which
are executed on provider side.
Fields are combinations of one or more of the following three
• a notifier which sends data on change from the provider to the subscribers
• a getter which can be called by the subscriber to explicitely query the provider for
the value
• a setter which can be called by the subscriber when it wants to change the value
on provider side
The major difference between the notifier of a field and an event is that evetns are
only sent on change, the notifier of a filed additionally sends the data directly after
subscription.
4.1 Specification of SOME/IP on wire-format (Serialization)

Serialization describes the way data is represented in protocol data units (PDUs) as
payload of either UDP or TCP messages, transported over an IP-based automotive
in-vehicle network.
4.1.1 Header
[PRS_SOMEIP_00030] d

The structure of header layout is as shown in the Figure 4.1. c(RS_SOMEIP_00027)
Figure 4.1: SOME/IP Header Format
[PRS_SOMEIP_00031] d For interoperability reasons the header layout shall be identi-

cal for all implementations of SOME/IP. The fields are presented in transmission order
i.e. the fields on the top left are transmitted first. c(RS_SOMEIP_00027)
4.1.1.1 Message ID [32 Bit]
[PRS_SOMEIP_00034] d The Message ID shall be a 32 Bit identifier that is used

to identify the RPC call to a method of an application or to identify an event. c
(RS_SOMEIP_00027)
[PRS_SOMEIP_00035] d The assignment of the Message ID shall be up to the user.
However, the Message ID shall be unique for the whole system (i.e. the vehicle). The
Message ID is similar to a CAN ID and should be handled via a comparable process.
c(RS_SOMEIP_00027)
[PRS_SOMEIP_00038] d Message IDs of method calls shall be structured in the ID
with 216 services with 215 methods as shown in Table 4.1
c(RS_SOMEIP_00027)
Service ID [16 Bit] 0 [1 Bit] Method ID [last 15 Bit]
Table 4.1: Structure of ID
4.1.1.2 Length [32 Bit]
[PRS_SOMEIP_00042] d Length field shall contain the length in Byte starting from
Request ID/Client ID until the end of the SOME/IP message. c(RS_SOMEIP_00027)

4.1.1.3 Request ID [32 Bit]
The Request ID allows a provider and subscriber to differentiate multiple parallel uses
of the same method, event, getter or setter.
[PRS_SOMEIP_00043] d The Request ID shall be unique for a provider- and
subscriber-combination (i.e. one subscription) only. c(RS_SOMEIP_00027)
[PRS_SOMEIP_00704] d When generating a response message, the provider
shall copy the Request ID from the request to the response message. c
(RS_SOMEIP_00027) Note:
This allows the subscriber to map a response to the issued request even with more
than one request outstanding.
[PRS_SOMEIP_00044] d Request IDs must not be reused until the response is arrived
or is not expected to arrive anymore (timeout). c(RS_SOMEIP_00027)
4.1.1.3.1 Structure of the Request ID
[PRS_SOMEIP_00046] d In AUTOSAR the Request ID shall be constructed of the

Client ID and Session ID as shown in Table 4.2
c(RS_SOMEIP_00027)
Client ID [16 Bits] Session ID [16 Bits]
Table 4.2: Structure of Request ID
Note:
This means that the implementer of an ECU can define the Client-IDs as required by
his implementation and the provider does not need to know this layout or definitions
because he just copies the complete Request-ID in the response.
[PRS_SOMEIP_00702] d The Client ID is the unique identifier for the calling client
inside the ECU. The Client ID allows an ECU to differentiate calls from multiple clients
to the same method. c(RS_SOMEIP_00027)
[PRS_SOMEIP_00703] d The Session ID is a unique identifier chosen by the sub-
scribers for each call. The Session ID allows a subscriber to differentiate multiple calls
to the same method. c(RS_SOMEIP_00027)
[PRS_SOMEIP_00532] d The Client ID shall also support being unique in the over-
all vehicle by having a configurable prefix or fixed value (e.g. the most significant
byte of Client ID being the diagnostics address or a configured Client ID for a given
application/SW-C). c()
For example:
Client ID Prefix [8 Client ID [8 Bits] Session ID [16 Bits]

Bits]

Table 4.3: Example of Client ID
[PRS_SOMEIP_00533] d Request/Response methods shall use session handling

with Session IDs. Session ID should be incremented after each call. c
(RS_SOMEIP_00027)
[PRS_SOMEIP_00521] d When the Session ID reaches 0xFFFF, it shall wrap around
and start again. c(RS_SOMEIP_00027)
[PRS_SOMEIP_00739] d A subscriber has to ignore a reponse if the session id of
reponse does not equal the session id of request. c(RS_SOMEIP_00027)
4.1.1.4 Protocol Version [8 Bit]
[PRS_SOMEIP_00052] d Protocol Version shall be an 8 Bit field containing the

SOME/IP protocol version. c(RS_SOMEIP_00027)
4.1.1.5 Interface Version [8 Bit]
[PRS_SOMEIP_00053] d Interface Version shall be an 8 Bit field that contains the

Major Version of the Service Interface. c(RS_SOMEIP_00027)
4.1.1.6 Message Type [8 Bit]
[PRS_SOMEIP_00055] d The Message Type field is used to differentiate different

types of messages and shall contain the following values as shown in Table 4.4
c(RS_SOMEIP_00027)
Number Value Description

0x00 REQUEST A request expecting a response (even
void)
0x01 REQUEST_NO_RETURN A fire&forget request
0x02 NOTIFICATION A request of a notification/event callback
expecting no response
0x80 RESPONSE The response message
0x81 ERROR The response containing an error)
0x20 TP_REQUEST A TP request expecting a response (even
void)
0x21 TP_REQUEST_NO_RETURN A TP fire&forget request
0x22 TP_NOTIFICATION A TP request of a notification/event call-
back expecting no response
0x23 TP_RESPONSE The TP response message
0x24 TP_ERROR The TP response containing an error)

Table 4.4: Message Types
[PRS_SOMEIP_00701] d Regular request (message type 0x00) shall be answered by

a response (message type 0x80), when no error occurred. If errors occur an error
message (message type 0x81) shall be sent. c(RS_SOMEIP_00027)
It is also possible to send a request that does not have a response message (mes-
sage type 0x01). For updating values through notification a callback interface exists
(message type 0x02).
[PRS_SOMEIP_00367] d The 3rd highest bit of the Message Type (=0x20) shall be
called TP-Flag and shall be set to 1 to signal that the current SOME/IP message is a
segment. The other bits of the Message Type are set as specified in this Section. c
(RS_SOMEIP_00027, RS_SOMEIP_00051) Note:
Segments of the Message Type Request (0x00) have the Message Type (0x20), seg-
ments of the Message Type Response (0x80) have the Message Type (0xa0), and so
on. For details see (Chapter 4.2.1.4)
4.1.1.7 Return Code [8 Bit]
[PRS_SOMEIP_00058] d The Return Code shall be used to signal whether a request

was successfully processed. For simplification of the header layout, every message
transports the field Return Code. The allowed Return Codes for specific message
types are shown in Table 4.5 c(RS_SOMEIP_00027)
Message Type Allowed Return Codes

REQUEST N/A set to 0x00 (E_OK)
REQUEST_NO_RETURN N/A set to 0x00 (E_OK)
NOTIFICATION N/A set to 0x00 (E_OK)
RESPONSE See Return Codes in [PRS_SOMEIP_00191]
ERROR See Return Codes in [PRS_SOMEIP_00191]. Shall not be
0x00 (E_OK).
Table 4.5: Allowed Return Codes for spcific Message Types
4.1.1.8 Payload [variable size]
In the payload field the parameters are carried. The serialization of the parameters will
be specified in the following section.
The size of the SOME/IP payload field depends on the transport protocol used. With
UDP the SOME/IP payload shall be between 0 and 1400 Bytes. The limitation to 1400
Bytes is needed in order to allow for future changes to protocol stack (e.g. changing to

IPv6 or adding security means). Since TCP supports segmentation of payloads, larger
sizes are automatically supported.
Payload might consists of data elements for events or parameters for methods.
4.1.2 Event, Field and Eventgroup
Eventgroup is a logical grouping of events and notification events of fields inside a

service in order to allow subscription.
[PRS_SOMEIP_00040] d Events and notifications are transported using RPC, Events
shall be structured as shown in Table 4.6
c(RS_SOMEIP_00027)
Service ID [16 Bit] 1 [1 Bit] Event ID [last 15 Bit]
Table 4.6: Structure of Event ID
[PRS_SOMEIP_00365] d Empty eventgroups shall not be used. c

(RS_SOMEIP_00027)
[PRS_SOMEIP_00366] d Events as well as fields are mapped to at least one event-
group. c(RS_SOMEIP_00027)
4.1.3 Endianess
[PRS_SOMEIP_00368] d SOME/IP Header shall be encoded in network byte order

(big endian). c(RS_SOMEIP_00026)
[PRS_SOMEIP_00369] d The byte order of the parameters inside the payload shall be
defined by configuration. c(RS_SOMEIP_00026)
4.1.4 Serialization of Data Structures
The serialization is based on the parameter list defined by the interface specification.
The interface specification defines the exact position of all data structures in the PDU
and has to consider the memory alignment.
Alignment is used to align the beginning of data by inserting padding elements after
the data in order to ensure that the aligned data starts at certain memory addresses.
There are processor architectures which can access data more efficiently (i.e. master)
when they start at addresses which are multiples of a certain number (e.g multiples of
32 Bit).

[PRS_SOMEIP_00611] d Alignment of data shall be realized by inserting padding

elements between the preceding data and the data that shall be aligned. c
(RS_SOMEIP_00028)
[PRS_SOMEIP_00569] d Alignment shall always be calculated from start of SOME/IP
message. c(RS_SOMEIP_00028)
[PRS_SOMEIP_00612] d There shall be no padding behind fixed length data elements
to ensure alignment of the following data. c(RS_SOMEIP_00028)
Note:
If data behind fixed length data elements shall be padded, this has to be explicitly
considered in the data type definition.
[PRS_SOMEIP_00063] d The serialization shall not try to automatically align data
structures but shall be aligned as specified in the interface specification. c
(RS_SOMEIP_00028)
[PRS_SOMEIP_00613] d The alignment of data behind variable length data elements
shall be a multiple of 8, 16 or 32 Bits. c(RS_SOMEIP_00028)
4.1.4.1 Basic Datatypes
[PRS_SOMEIP_00065] d The following basic datatypes as shown in Table 4.7 shall be

supported:
c(RS_SOMEIP_00030, RS_SOMEIP_00031, RS_SOMEIP_00032)
Type Description Size [bit] Remark

boolean TRUE/FALSE value 8 FALSE (0), TRUE (1)
uint8 unsigned Integer 8
sint8 signed Integer 8
float32 floating point number 32 IEEE 754 binary32 (Single Preci-
sion)
float64 floating point number 64 IEEE 754 binary64 (Double Preci-
sion)
Table 4.7: Supported basic Data Types
The Byte Order is specified for each parameter by configuration.

[PRS_SOMEIP_00615] d For the evaluation of a Boolean value only the lowest
bit of the uint8 is interpreted and the rest is ignored. c(RS_SOMEIP_00030,
RS_SOMEIP_00031, RS_SOMEIP_00032)

4.1.4.2 Structured Datatypes (structs)
The serialization of a struct shall be close to the in-memory layout. This means, only
the parameters shall be serialized sequentially into the buffer. Especially for structs it
is important to consider the correct memory alignment.
Struct_1 uint32 a
float32 b_1
uint32 a float32 b_2
float32 b[2] serialization uint32 d
float32 e_1
Example:
Struct_2 c Struct_2 float32 e_2
…
uint32 d
float32 e[2]
Struct_3 f
Figure 4.2: Serialization of Structs
[PRS_SOMEIP_00077] d The SOME/IP implementation shall not automatically insert

dummy/padding data. c(RS_SOMEIP_00033)
[PRS_SOMEIP_00079] d An optional length field of 8, 16 or 32 Bit may be inserted in
front of the Struct depending on the configuration. c(RS_SOMEIP_00033)
[PRS_SOMEIP_00370] d The length field of the struct shall describe the number of
bytes this struct occupies for SOME/IP transport. c(RS_SOMEIP_00033)
[PRS_SOMEIP_00371] d If the length is greater than the length of the struct as
specified in the data type definition only the bytes specified in the data type shall
be interpreted and the other bytes shall be skipped based on the length field. c
(RS_SOMEIP_00033)
[PRS_SOMEIP_00900] d If the length is less than the sum of the lengths of all struct
members and no substitution for the missing data can be provided locally by the re-
ceiver, the deserialization shall be aborted and the message shall be treated as mal-
formed. c(RS_SOMEIP_00033)
[PRS_SOMEIP_00712] d The serialization of structs shall follow the depth-first-
traversal of the structured data type. c(RS_SOMEIP_00033)

4.1.4.3 Strings
Following requirements are common for both fixed length and dynamic legth strings.
[PRS_SOMEIP_00372] d Different Unicode encoding shall be supported including
UTF-8, UTF-16BE and UTF-16LE. c(RS_SOMEIP_00038)
[PRS_SOMEIP_00084] d UTF-16LE and UTF-16BE strings shall be zero terminated
with a "\0" character. This means they shall end with (at least) two 0x00 Bytes. c
(RS_SOMEIP_00038)
[PRS_SOMEIP_00085] d UTF-16LE and UTF-16BE strings shall have an even length.
c(RS_SOMEIP_00038)
[PRS_SOMEIP_00086] d UTF-16LE and UTF-16BE strings having a odd length the
last byte shall be ignored. The two bytes before shall be 0x00 bytes (termination). c
(RS_SOMEIP_00038)
[PRS_SOMEIP_00087] d All strings shall always start with a Byte Order Mark (BOM).
The BOM shall be included in fixed-length-strings as well as dynamic-length strings.
BOM allows the possibility to detect the used encoding. c(RS_SOMEIP_00038)
4.1.4.3.1 Strings (fixed length)
[PRS_SOMEIP_00373] d Strings shall be terminated with a "\0"-character despite hav-

ing a fixed length. c(RS_SOMEIP_00038)
[PRS_SOMEIP_00374] d The length of the string (this includes the "\0") in Bytes has to
be specified in the data type definition. Fill unused space using "\0". BOM is included
in the length. c(RS_SOMEIP_00038)
[PRS_SOMEIP_00911] d If the length of a string with fixed length is greater than ex-
pected (expectation shall be based on the data type definition), the deserialization shall
be aborted and the message shall be treated as malformed. c(RS_SOMEIP_00038)
[PRS_SOMEIP_00912] d If the length of a string with fixed length is less than expected
(expectation shall be based on the data type definition) and it is correctly terminated
using "\0", it shall be accepted. c(RS_SOMEIP_00038)
[PRS_SOMEIP_00913] d If the length of a string with fixed length is less than expected
(expectation shall be based on the data type definition) and it is not correctly terminated
using "\0", the deserialization shall be aborted and the message shall be treated as
malformed. c(RS_SOMEIP_00038)
4.1.4.3.2 Strings (dynamic length)
[PRS_SOMEIP_00089] d Strings with dynamic length shall start with a length field.
The length is measured in Bytes. c(RS_SOMEIP_00039)

[PRS_SOMEIP_00090] d The length field is placed before the BOM, and the BOM is
included in the length. c(RS_SOMEIP_00039)
[PRS_SOMEIP_00091] d String are terminated with a "\0". c(RS_SOMEIP_00039)
Note:
The maximum number of bytes of the string (including termination with "\0") shall also
be derived from the data type definition.
[PRS_SOMEIP_00092] d [PRS_SOMEIP_00084], [PRS_SOMEIP_00085] and
[PRS_SOMEIP_00086] shall also be valid for strings with dynamic length. c
(RS_SOMEIP_00039)
[PRS_SOMEIP_00093] d Dynamic length strings shall have a length field of 8, 16 or
32 Bit. This length is defined by the Interface Specification. c(RS_SOMEIP_00039)
[PRS_SOMEIP_00094] d If not specified otherwise in the interface specification the
length of the length field is 32 Bit (default length of length field). c(RS_SOMEIP_00039)
[PRS_SOMEIP_00095] d The length of the Strings length field is not considered
in the value of the length field; i.e. the length field does not count itself. c
(RS_SOMEIP_00039)
[PRS_SOMEIP_00914] d If the length of a string with variable length is greater than ex-
pected (expectation shall be based on the data type definition), the deserialization shall
be aborted and the message shall be treated as malformed. c(RS_SOMEIP_00038)
Instead of transferring application strings as SOME/IP strings with BOM and "\0" ter-
mination, strings can also be transported as plain dynamic length arrays without BOM
and "\0" termination (see chapter 4.1.4.5). Please note that this requires the full string
handling (e.g. endianness conversion) to be done in the applications.
4.1.4.4 Arrays (fixed length)
The length of fixed length arrays is defined by the data type definition. They can be
seen as repeated elements. In chapter 4.1.4.5 dynamic length arrays are shown, which
can be also used. Fixed length arrays are easier for use in very small devices. Dynamic
length arrays might need more resources on the ECU using them.
[PRS_SOMEIP_00917] d If the length of an fixed length array is greater than expected
(expectation shall be based on the data type definition) only the elements specified in
the data type shall be interpreted and the other bytes shall be skipped based on the
length field. c(RS_SOMEIP_00036)
[PRS_SOMEIP_00918] d If the length of a fixed length array is less than expected (ex-
pectation shall be based on the data type definition) and no substitution for the missing
data can be provided locally by the receiver, the deserialization shall be aborted and
the message shall be treated as malformed. c(RS_SOMEIP_00036)

4.1.4.4.1 One-dimensional
The one-dimensional arrays with fixed length "n" shall carry exactly "n" elements
of the same type. The layout is shown in Figure 4.3. c(RS_SOMEIP_00035,
RS_SOMEIP_00036)
Static Array a[n]

Element_1 Element_2 Element_3 Element_n
…
element size e
n*e
Figure 4.3: One-dimensional array (fixed length)
4.1.4.4.2 Multidimensional
The serialization of multidimensional arrays follows the in-memory layout of multidi-
mensional arrays in the programming language (row-major order) and is shown in
Figure 4.4. c(RS_SOMEIP_00035, RS_SOMEIP_00036)
Static Array a[n][m]

Element_1 Element_2 Element_n
E1,1 E1,2 E1,m
…
…
e
m*e
n*(m*e)
Figure 4.4: Multidimensional array (fixed length)

4.1.4.5 Dynamic Length Arrays
[PRS_SOMEIP_00375] d The layout of arrays with dynamic length shall be based on

the layout of fixed length arrays. c(RS_SOMEIP_00037)
[PRS_SOMEIP_00376] d An optional length field at the beginning of an array should
be used to specify the length of the array in Bytes. c(RS_SOMEIP_00037)
[PRS_SOMEIP_00107] d The length field shall have a length of 0, 8, 16 or 32 Bits.
This shall be determined by configuration. c(RS_SOMEIP_00037)
[PRS_SOMEIP_00377] d The length does not include the size of the length field. c
(RS_SOMEIP_00037)
Note:
If the length of the length field is set to 0 Bits, the number of elements in the array has
to be fixed; thus, being an array with fixed length.
The layout of dynamic arrays is shown in Figure 4.5 and Figure 4.6.
Length n Element_1 Element_2 Element_3 Element_n

…
32 Bit element size e
n [Bytes]
Figure 4.5: One-dimensional array (dynamic length)
In the one-dimensional array one length field is used, which carries the number of bytes
used for the array.
The number of static length elements can be easily calculated by dividing by the size
of an element.
In the case of dynamical length elements the number of elements cannot be calculated,
but the elements must be parsed sequentially.
Figure 4.6 shows the structure of a Multidimensional Array of dynamic length.

Length n Element_a[1][j…k_1] Element_a[2][j…k_2]

L_2 E1,1
L_1 E1,1 E1,2
… E1,k_1 E1,2
… E1,k_2
…
L_1 [Bytes] L_2 [Bytes]

32 Bit 32 Bit 32 Bit
n [Bytes]
Figure 4.6: Multidimensional array (dynamic length)
[PRS_SOMEIP_00114] d In multidimensional arrays every sub array of different di-

mensions shall have its own length field. c(RS_SOMEIP_00037)
If static buffer size allocation is required, the data type definition shall define the maxi-
mum length of each dimension.
Rationale: When measuring the length in Bytes, complex multi-dimensional arrays can
be skipped over in deserialization.
SOME/IP also supports that different length for columns and different length for rows
in the same dimension. See k_1 and k_2 in Figure 4.6. A length indicator needs to
be present in front of every dynamic length array. This applies for both outer and all
inner/nested arrays.
[PRS_SOMEIP_00919] d If the length of an variable length array is greater than ex-
pected (expectation shall be based on the data type definition) only the elements spec-
ified in the data type shall be interpreted and the other bytes shall be skipped based
on the length field. c(RS_SOMEIP_00037)
4.1.4.6 Enumeration
[PRS_SOMEIP_00705] d Enumerations are not considered in SOME/IP. Enumerations

shall be transmitted as unsigned integer datatypes. c(RS_SOMEIP_00033)
4.1.4.7 Bitfield
[PRS_SOMEIP_00300] d Bitfields shall be transported as unsigned datatypes

uint8/uint16/uint32. c(RS_SOMEIP_00033)
The data type definition will be able to define the name and values of each bit.

4.1.4.8 Union / Variant
There are use cases for defining data as unions on the network where the payload can
be of different data types.
A union (also called variant) is such a parameter that can contain different types of
data. For example, if one defines a union of type uint8 and type uint16, the union shall
carry data which are a uint8 or a uint16.
Which data type will be transmitted in the payload can only be decided during execu-
tion. In this case, however, it is necessary to not only send the data itself but add an
information about the applicable data type as a form of "meta-data" to the transmission.
By the means of the attached meta-data the sender can identify the applicable data
type of the union and the receiver can accordingly access the data properly.
[PRS_SOMEIP_00118] d A union shall be used to transport data with alternative data
types over the network. c(RS_SOMEIP_00034)
[PRS_SOMEIP_00119] d A union shall consist of a length field, type selector and the
payload as shown in Table 4.8: c(RS_SOMEIP_00034)
Length field [32 bit]

Type field [32 bit]
Data including padding [sizeof(padding) = length - sizeof(data)]
Table 4.8: Default Serialization of Unions
[PRS_SOMEIP_00126] d The length field shall define the size of the data and
padding in bytes and does not include the size of the length field and type field. c
(RS_SOMEIP_00034)
Note:
The padding can be used to align following data in the serialized data stream if config-
ured accordingly.
[PRS_SOMEIP_00121] d The length of the length field shall be defined by configuration
and shall be 32, 16, 8, or 0 bits c(RS_SOMEIP_00034)
[PRS_SOMEIP_00122] d A length of the length field of 0 Bit means that no length field
will be written to the PDU. c(RS_SOMEIP_00034)
[PRS_SOMEIP_00123] d If the length of the length field is 0 Bit, all types in the union
shall be of the same length. c(RS_SOMEIP_00034)
[PRS_SOMEIP_00129] d The type field shall specify the data type of the data. c
(RS_SOMEIP_00034)
[PRS_SOMEIP_00127] d The length of the type field shall be defined by configuration
and shall be 32, 16, or 8 bits. c(RS_SOMEIP_00034)

[PRS_SOMEIP_00906] d Possible values of the type field shall be defined by the con-
figuration for each union separately. c(RS_SOMEIP_00034)
[PRS_SOMEIP_00907] d The value 0 of the type field shall be reserved for the NULL
type. c(RS_SOMEIP_00034)
Note:
This denotes an empty union.
[PRS_SOMEIP_00908] d Whether NULL is allowed for a union or not shall be defined
by configuration. c(RS_SOMEIP_00034)
[PRS_SOMEIP_00130] d The payload is serialized depending on the type in the type
field. c(RS_SOMEIP_00034)
In the following example a length of the length field is specified as 32 Bits. The union
shall support a uint8 and a uint16 as data. Both are padded to the 32 bit boundary
(length=4 Bytes).
A uint8 will be serialized like shown in Table 4.9.
Length = 4 Bytes
Type = 1
uint8 Padding 0x00 Padding 0x00 Padding 0x00
Table 4.9: Example: uint8
A uint16 will be serialized like shown in Table 4.10.

Length = 4 Bytes
Type = 2
uint16 Padding 0x00 Padding 0x00
Table 4.10: Example: uint16
[PRS_SOMEIP_00915] d If the length of a union is greater than expected (expectation

shall be based on the data type definition) only the bytes specified in the data type
shall be interpreted and the other bytes shall be skipped based on the length field. c
(RS_SOMEIP_00034)
[PRS_SOMEIP_00916] d If the length of a union is less than expected (expectation
shall be based on the data type definition) it shall depend on the inner data type
whether valid data can be deserialized or the deserialization shall be aborted and the
message shall be treated as malformed. c(RS_SOMEIP_00034)
4.2 Specification of SOME/IP Protocol

This chapter describes the Remote Procedure Call(RPC), Event Notifications and Error
Handling of SOME/IP.

4.2.1 Transport Protocol Bindings
In order to transport SOME/IP messages different transport protocols may be used.

SOME/IP currently supports UDP and TCP. Their bindings are explained in the follow-
ing sections, while Chapter 6 discusses which transport protocol to choose.
[PRS_SOMEIP_00138] d If a server runs different instances of the same service, mes-
sages belonging to different service instances shall be mapped to the service instance
by the transport protocol port on the server side. For details see Chapter 4.2.1.3 c
(RS_SOMEIP_00010)
[PRS_SOMEIP_00535] d All Transport Protocol Bindings shall support transporting
more than one SOME/IP message in a Transport Layer PDU (i.e. UDP packet or TCP
segment). c(RS_SOMEIP_00010)
[PRS_SOMEIP_00142] d The receiving SOME/IP implementation shall be capa-
ble of receiving unaligned SOME/IP messages transported by UDP or TCP. c
(RS_SOMEIP_00010)
Rationale:
When transporting multiple SOME/IP payloads in UDP or TCP the alignment of the
payloads can be only guaranteed, if the length of every payloads is a multiple of the
alignment size (e.g. 32 bits).
4.2.1.1 UDP Binding
[PRS_SOMEIP_00139] d The UDP binding of SOME/IP shall be achieved by trans-

porting SOME/IP messages in UDP packets. c(RS_SOMEIP_00010)
[PRS_SOMEIP_00137] d SOMEIP protocol shall not restrict the usage of UPD frag-
mentation. c(RS_SOMEIP_00010)
[PRS_SOMEIP_00140] d 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 length field, SOME/IP shall determine if there are additional SOME/IP messages
in the UDP packet. c(RS_SOMEIP_00010)
[PRS_SOMEIP_00141] d Each SOME/IP payload shall have its own SOME/IP header.
c(RS_SOMEIP_00010)
4.2.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 bigger SOME/IP messages and uses the
robustness features of TCP (coping with loss, reorder, duplication, etc.).

In order to lower latency and reaction time, Nagle’s algorithm should be turned off
(TCP_NODELAY).
[PRS_SOMEIP_00706] d When the TCP connection is lost, outstanding requests shall
be handled as timeouts. c(RS_SOMEIP_00010) Since TCP handles reliability, addi-
tional means of reliability are not needed.
[PRS_SOMEIP_00707] d The client and server shall use a single TCP connection
for all methods, events, and notifications of a service instance. When having more
than one instance of a service a TCP connection per services instance is needed. c
(RS_SOMEIP_00010)
[PRS_SOMEIP_00708] d The TCP connection shall be opened by the client, when the
first method call shall be transported or the client tries to receive the first notifications.
c(RS_SOMEIP_00010)
The client is responsible for reestablishing the TCP connection whenever it fails.
[PRS_SOMEIP_00709] d The TCP connection shall be closed by the client, when the
TCP connection is not required anymore. c(RS_SOMEIP_00010)
[PRS_SOMEIP_00710] d The TCP connection shall be closed by the client, when all
Services using the TCP connections are not available anymore (stopped or timed out).
c(RS_SOMEIP_00010)
[PRS_SOMEIP_00711] d The server shall not stop the TCP connection when stopping
all services. Give the client enough time to process the control data to shutdown the
TCP connection itself. c(RS_SOMEIP_00010)
Rational:
When the server closes the TCP connection before the client recognized that the TCP
is not needed anymore, the client will try to reestablish the TCP connection.
4.2.1.2.1 Allowing resync to TCP stream using Magic Cookies
[PRS_SOMEIP_00154] d In order to allow testing tools to identify the boundaries

of SOME/IP Message transported via TCP, the SOME/IP Magic Cookie Message
(Figure 4.7) may be inserted into the SOME/IP messages over TCP message stream
at regular distances. c(RS_SOMEIP_00010)
The layout of the Magic Cookie Messages is shown in Figure 4.7. c
(RS_SOMEIP_00010)

Client Server:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 bit offset
Message ID (Service ID / Method ID ) [32 bit]
(= 0xFFFF 0000 )
Length [32 bit]
= 0x0000 0008
Request ID (Client ID / Session ID) [32 bit]
by Length
Covered
= 0xDEAD BEEF
Protocol Version [8 bit] Interface Version [8 bit] Message Type [8 bit] Return Code [8 bit]
=0x01 =0x01 =0x01 =0x00
Server Client:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 bit offset
Message ID (Service ID / Method ID ) [32 bit]
(= 0xFFFF 8000 )
Length [32 bit]
= 0x0000 0008
Request ID (Client ID / Session ID) [32 bit]
by Length
Covered
= 0xDEAD BEEF
Protocol Version [8 bit] Interface Version [8 bit] Message Type [8 bit] Return Code [8 bit]
=0x01 =0x01 =0x02 =0x00
Figure 4.7: SOME/IP Magic Cookie Message for SOME/IP
4.2.1.3 Multiple Service-Instances
[PRS_SOMEIP_00162] d Service-Instances of the same Service are identified through

different Instance IDs. It shall be supported that multiple Service-Instances reside on
different ECUs as well as multiple Service-Instances of one or more Services reside
on one single ECU. c(RS_SOMEIP_00011)
[PRS_SOMEIP_00163] d While different Services shall be able to share the same
port number of the transport layer protocol used, multiple Service-Instances of the
same service on one single ECU shall listen on different ports per Service-Instance. c
(RS_SOMEIP_00011) Rationale: While Instance IDs are used for Service Discovery,
they are not contained in the SOME/IP header.
A Service Instance can be identified through the combination of the Service ID com-
bined with the socket (i.e. IP-address, transport protocol (UDP/TCP), and port num-
ber). It is recommended that instances use the same port number for UDP and TCP. If
a service instance uses UDP port x, only this instance of the service and not another
instance of the same service should use exactly TCP port x for its services.

4.2.1.4 Transporting large SOME/IP messages of UDP (SOME/IP-TP)
The UDP binding of SOME/IP can only transport SOME/IP messages that fit directly
into an IP packet. If larger SOME/IP messages need to be transported over UDP
(e.g. of 32 KB) the SOME/IP Transport Protocol (SOME/IP-TP) shall be used. The
SOME/IP message too big to be transported directly with the UDP binding shall be
called "original" SOME/IP message. The "pieces" of the original SOME/IP message
payload transported in SOME/IP-TP messages shall be called "segments".
Use TCP only if very large chunks of data need to be transported (> 1400 Bytes) and
no hard latency requirements in the case of errors exists
[PRS_SOMEIP_00720] d SOME/IP messages using SOME/IP-TP shall activate
Session Handling (Session ID must be unique for the original message). c
(RS_SOMEIP_00010, RS_SOMEIP_00011)
[PRS_SOMEIP_00721] d All SOME/IP-TP segments shall carry the Session ID of the
original message; thus, they have all the same Session-ID. c(RS_SOMEIP_00010,
RS_SOMEIP_00011)
[PRS_SOMEIP_00722] d SOME/IP-TP segments shall have the TP-Flag of the Mes-
sage Type set to 1. c(RS_SOMEIP_00010, RS_SOMEIP_00011)
SOME-IP-TP-Header is as shown in Figure 4.8. SOME/IP-TP segments shall have a
TP header right after the SOME/IP header (i.e. before the SOME/IP payload) with the
following structure (bits from highest to lowest):
• Offset [28 bits]
• Reserved Flag [1 bit]
• More Segments Flag [1 bit]
c(RS_SOMEIP_00010, RS_SOMEIP_00011)

Figure 4.8: SOME/IP TP header
[PRS_SOMEIP_00724] d The Offset field shall transport the upper 28 bits of a

uint32. The lower 4 bits shall be always be interpreted as 0. c(RS_SOMEIP_00010,
RS_SOMEIP_00011) Note:
This means that the offset field can only transport offset values that are multiples of 16
bytes.
[PRS_SOMEIP_00725] d The Offset field of the TP header shall be set to the offset
in bytes of the transported segment in the original message. c(RS_SOMEIP_00010,
RS_SOMEIP_00011)
[PRS_SOMEIP_00726] d The Reserved Flags shall be set to 0 by the sender
and shall be ignored (and not checked) by the receiver. c(RS_SOMEIP_00010,
RS_SOMEIP_00011)
[PRS_SOMEIP_00727] d The More Segments Flag shall be set to 1 for all segments
but the last segment. For the last segment it shall be set to 0. c(RS_SOMEIP_00010,
RS_SOMEIP_00011)
[PRS_SOMEIP_00728] d The SOME/IP length field shall be used as specified before.
This means it covers the first 8 bytes of the SOME/IP header and all bytes after that. c
This means that for a SOME/IP-TP message transporting a segment, the SOME/IP
length covers 8 bytes of the SOME/IP header, the 4 bytes of the TP header, and the
segment itself.
[PRS_SOMEIP_00729] d The length of a segment must reflect the alignment of the
next segment based on the offset field. Therefore, all but the last segment shall have
a length that is a multiple of 16 bytes. c(RS_SOMEIP_00010, RS_SOMEIP_00011)
[PRS_SOMEIP_00730] d Since UDP-based SOME/IP messages are limited to 1400
bytes payload, the maximum length of a segment that is correctly aligned is 1392 bytes.

[PRS_SOMEIP_00731] d SOME/IP-TP messages shall use the same Message ID

(i.e. Service ID and Method ID), Request ID (i.e. Client ID and Session ID),
Protocol Version, Interface Version, and Return Code as the original message. c
As described above the Length, Message Type, and Payload are adapted by SOME/IP-
TP.
4.2.1.4.1 Example
This example describes how an original SOME/IP message of 5880 bytes payload has
to be transmitted. The Length field of this original SOME/IP message is set to 8 + 5880
bytes.
Figure 4.9: Example: Header of Original SOME/IP message
This original SOME/IP message will now be segmented into 5 consecutive SOME/IP
segments. Every payload of these segments carries at most 1392 bytes in this exam-
ple.
For these segments, the SOME/IP TP module adds additional TP fields (marked red).
The Length field of the SOME/IP carries the overall length of the SOME/IP segment
including 8 bytes for the Request ID, Protocol Version, Interface Version, Message Type
and Return Code. Because of the added TP fields (4 bytes), this Length information is
extended by 4 additional SOME/IP TP bytes.
The following figure provides an overview of the relevant SOME/IP header settings for
every SOME/IP segment:

Figure 4.10: Example: Overview of relevant SOME/IP TP headers
Note:
Please be aware that the value provided within the Offset Field is given in units of 16
bytes, i.e.: The Offset Value of 87 correspond to 1392 bytes Payload.
The complete SOME/IP headers of the SOME/IP segments message will look like this
in detail:
• The first 4 segments contain 1392 Payload bytes each with "More Segments
Flag" set to ’1’:
Figure 4.11: Example: Header of the SOME/IP segments
• The last segment (i.e. #5) contains the remaining 312 Payload bytes of the origi-
nal 5880 bytes payload. This last segment is marked with "More Segments flag"
set to ’0’.

Figure 4.12: Example: Header of the last SOME/IP segment
4.2.1.4.2 Sender specific behavior
[PRS_SOMEIP_00732] d The sender shall segment only messages that were config-
ured to be segmented. c(RS_SOMEIP_00010, RS_SOMEIP_00011)
[PRS_SOMEIP_00733] d The sender shall send segments in ascending order. c
[PRS_SOMEIP_00734] d The sender shall segment in a way that all segments with
the More Segment Flag set to 1 are of the same size. c(RS_SOMEIP_00010,
RS_SOMEIP_00011)
[PRS_SOMEIP_00735] d The sender shall try to maximize the size of segments within
limitations imposed by this specification. c(RS_SOMEIP_00010, RS_SOMEIP_00011)
[PRS_SOMEIP_00736] d The sender shall not send overlapping or duplicated seg-
ments. c(RS_SOMEIP_00010, RS_SOMEIP_00011)
4.2.1.4.3 Receiver specific behavior
[PRS_SOMEIP_00738] d The receiver shall match segments for reassembly based

on the configured values of Message-ID, Protocol-Version, Interface-Version and
Message-Type (w/o TP Flag). c(RS_SOMEIP_00010, RS_SOMEIP_00011)
[PRS_SOMEIP_00740] d It shall be supported to reassemble multiple messages with
the same Message ID but sent from different clients (difference in Sender IP, Sender

Port, or Client ID) in parallel. This should be controlled by configuration and determines
the amount of "reassembly buffers". c(RS_SOMEIP_00010, RS_SOMEIP_00011)
[PRS_SOMEIP_00741] d The Session ID shall be used to detect the next original
message to be reassembled. c(RS_SOMEIP_00010, RS_SOMEIP_00011)
[PRS_SOMEIP_00742] d The receiver shall start a new reassembly (and may be throw
away old segments that were not successfully reassembled), if a new segment with a
different Session-ID is received. c(RS_SOMEIP_00010, RS_SOMEIP_00011)
[PRS_SOMEIP_00743] d The receiver should only reassemble up to its con-
figured buffer size and skip the rest of the message. c(RS_SOMEIP_00010,
RS_SOMEIP_00011)
[PRS_SOMEIP_00744] d Only correctly reassembled message of up to the configured
size shall be passed to an application. c(RS_SOMEIP_00010, RS_SOMEIP_00011)
Note:
This means that the implementation must make sure that all bytes of the message must
be bytes that were received and reassembled correctly. Counting non-overlapping,
non-duplicated bytes and comparing this to the length could be a valid check.
[PRS_SOMEIP_00745] d The Return Code of the last segment used for re-
assembly shall be used for the reassembled message. c(RS_SOMEIP_00010,
RS_SOMEIP_00011)
[PRS_SOMEIP_00746] d During reassembling the SOME/IP TP segments into a large
unsegmented message, the Message Type shall be adapted, the TP Flag shall be reset
to 0. c(RS_SOMEIP_00010, RS_SOMEIP_00011)
[PRS_SOMEIP_00747] d The receiver shall support reassembly of segments
that are received in ascending and descending order. c(RS_SOMEIP_00010,
RS_SOMEIP_00011)
[PRS_SOMEIP_00748] d The receiver should use limited resources to support re-
assembly of reordered segments of a single original message. At least a reorder
distance of 3 shall be supported (i.e. segments are allowed up to 3 positions away
from their correct place in sequence). c(RS_SOMEIP_00010, RS_SOMEIP_00011)
Note:
This could mean for example that the receiver can only desegment if segments are in
order but it stores the last 4 segments and sorts them before trying to deserialize. Or it
could mean that all segments are written into a buffer and 4 meta-data structures (e.g.
start and length) to store which data of the buffer is valid are present.
[PRS_SOMEIP_00749] d The receiver shall cancel desegmentation for a single origi-
nal message, if missing segments of this original message are detected and resources
do not permit to further wait on the segment (e.g. because the next message al-
ready starts or reorder distance is higher than expected). c(RS_SOMEIP_00010,
RS_SOMEIP_00011) Note:
This means that reordering inside a single original message is allowed, if ressources
permit this.

[PRS_SOMEIP_00750] d Interleaving of different segmented messages using the

same buffer (e.g. only the Session-ID and payload are different) is not supported.
Note:
This prohibits that equal events (same Message-ID, IP-Addresses, ports numbers, and
transport protocol) arrive in the wrong order, when some of their segments get re-
ordered.
[PRS_SOMEIP_00751] d Reordering of segments of completely different original mes-
sages (e.g. Message ID is different) is not of concern since those segments go to
different buffers. c(RS_SOMEIP_00010, RS_SOMEIP_00011)
[PRS_SOMEIP_00752] d The receiver shall correctly reassemble overlapping and
duplicated segments by overwriting based on the last received segment. c
[PRS_SOMEIP_00753] d The receiver may cancel reassembly, if overlapping or dupli-
cated segments change already written bytes in the buffer, if this feature can be turned
off by configuration. c(RS_SOMEIP_00010, RS_SOMEIP_00011)
[PRS_SOMEIP_00754] d The receiver shall be able to detect and handle obvious er-
rors gracefully. E.g. cancel reassembly if segment length of a segment with MS=1 is
not a multiple of 16. c(RS_SOMEIP_00010, RS_SOMEIP_00011) Note:
This means that buffer overflows or other malfunction shall must be prevented by the
receiving code.
4.2.2 Request/Response Communication
One of the most common communication patterns is the request/response pattern.

One communication partner (Client) sends a request message, which is answered by
another communication partner (Server).
[PRS_SOMEIP_00920] d For the SOME/IP request message the client has to do the
following for payload and header:
• Construct the payload
• Set the Message ID based on the method the client wants to call
• Set the Length field to 8 bytes (for the part of the SOME/IP header after the length
field) + length of the serialized payload
• Optionally set the Request ID to a unique number (shall be unique for client only)
• Set the Protocol Version according [PRS_SOMEIP_00052]
• Set the Interface Version according to the interface definition
• Set the Message Type to REQUEST (i.e. 0x00)

• Set the Return Code to 0x00

c(RS_SOMEIP_00007)
[PRS_SOMEIP_00921] d To construct the payload of a request message, all input
or inout arguments of the method shall be serialized according to the order of the
arguments within the signature of the method. c(RS_SOMEIP_00007)
[PRS_SOMEIP_00922] d The server builds the header of the response based on the
header of the client’s request and does in addition:
• take over the Message ID from the corresponding request
• Set the length to the 8 Bytes + new payload size
• take over the Request ID from the corresponding request
• Set the Message Type to RESPONSE (i.e. 0x80) or ERROR (i.e. 0x81)
• set Return Code to the return code of called method or in case of an Error mes-
sage to a valid error code (see Table 4.11)
c(RS_SOMEIP_00007)
[PRS_SOMEIP_00923] d To construct the payload of a response message, all output
or inout arguments of the method shall be serialized according to the order of the
arguments within the signature of the method. c(RS_SOMEIP_00007)
[PRS_SOMEIP_00927] d A server shall not sent a response message for a request
with a specific Request ID until the corresponding request message has been received.
c(RS_SOMEIP_00007)
[PRS_SOMEIP_00928] d A client shall ignore the reception of a response message
with a specific Request ID, when the corresponding request message has not yet been
sent completely. c(RS_SOMEIP_00007)
4.2.3 Fire&Forget Communication
Requests without response message are called fire&forget.

[PRS_SOMEIP_00924] d For the SOME/IP request-no-return message the client has
to do the following for payload and header:
• Set the Message ID based on the method the client wants to call
• Optionally set the Request ID to a unique number (shall be unique for client only)


• Set the Message Type to REQUEST_NO_RETURN (i.e. 0x01)
c(RS_SOMEIP_00006)
[PRS_SOMEIP_00171] d Fire & Forget messages shall not return an error. Error
handling and return codes shall be implemented by the application when needed. c
(RS_SOMEIP_00006)
4.2.4 Notification Events
Notifications describe a general Publish/Subscribe-Concept. Usually the server pub-

lishes a service to which a client subscribes. On certain cases the server will send the
client an event, which could be for example an updated value or an event that occurred.
SOME/IP is used only for transporting the updated value and not for the publishing and
subscription mechanisms. These mechanisms are implemented by SOME/IP-SD.
[PRS_SOMEIP_00925] d For the SOME/IP notification message the client has to do
the following for payload and header:
• Set the Message ID based on the event the server wants to send
• Set the Request ID to 0x0
• Set the Message Type to NOTIFICATION (i.e. 0x02)
c(RS_SOMEIP_00004)
[PRS_SOMEIP_00926] d The payload of the notification message shall consist of the
serialized data of the event. c(RS_SOMEIP_00004)
When more than one subscribed client on the same ECU exists, the system shall han-
dle the replication of notifications in order to save transmissions on the communication
medium. This is especially important, when notifications are transported using multi-
cast messages.

4.2.4.1 Strategy for sending notifications
For different use cases different strategies for sending notifications are possible. The
following examples are common:
• Cyclic update — send an updated value in a fixed interval (e.g. every 100 ms for
safety relevant messages with Alive)
• Update on change — send an update as soon as a "value" changes (e.g. door
open)
• Epsilon change — only send an update when the difference to the last value is
greater than a certain epsilon. This concept may be adaptive, i.e. the prediction is
based on a history; thus, only when the difference between prediction and current
value is greater than epsilon an update is transmitted.
4.2.5 Fields
A field represents a status and has a valid value. The consumers subscribing for the
field instantly after subscription get the field value as an initial event.
[PRS_SOMEIP_00179] d A field shall be a combination of getter, setter and notification
event. c(RS_SOMEIP_00009)
[PRS_SOMEIP_00180] d A field without a setter and without a getter and without a
notifier shall not exist. The field shall contain at least a getter, a setter, or a notifier. c
(RS_SOMEIP_00009)
[PRS_SOMEIP_00181] d The getter of a field shall be a request/response call that has
an empty payload in the request message and the value of the field in the payload of
the response message. c(RS_SOMEIP_00009)
[PRS_SOMEIP_00182] d The setter of a field shall be a request/response call that has
the desired value of the field in the payload of the request message and the value that
was set to the field in the payload of the response message. c(RS_SOMEIP_00009)
Note:
If the value of the request payload was adapted (e.g. because it was out of limits) the
adapted value will be transported in the response payload.
[PRS_SOMEIP_00909] d The notifier shall send an event message that transports
the value of the field to the client when the client subscribes to the field. c
(RS_SOMEIP_00009)
[PRS_SOMEIP_00183] d The notifier shall send an event message that transports the
value of a field on change and follows the rules for events. c(RS_SOMEIP_00009)

4.2.6 Error Handling
Error handling can be done in the application or the communication layer below. There-
fore SOME/IP supports two different mechanisms:
• Return Codes in the Response Messages of methods
• Explicit Error Messages
Which one of both is used, depends on the configuration.
[PRS_SOMEIP_00901] d Return Codes in the Response Messages of methods shall
be used to transport application errors and the response data of a method from the
provider to the caller of a method. c(RS_SOMEIP_00008)
Note:
Please be aware that return codes of the Request and Response methods are not
treated as errors from the point of view of SOME/IP. This means that the message type
is still 0x80 if a request/response method exits with a return code not equal to 0x00
(message type is still 0x80 if ApplicationError of AUTOSAR ClientServerOperation is
different from E_OK).
[PRS_SOMEIP_00902] d Explicit Error Messages shall be used to transport applica-
tion errors and the response data or generic SOME/IP errors from the provider to the
caller of a method. c(RS_SOMEIP_00008)
[PRS_SOMEIP_00903] d If more detailed error infromation need to be transmitted, the
payload of the Error Message (Message Type 0x81) shall be filled with error specific
data, e.g. an exception string. Error Messages shall be sent instead of Response
Messages. c(RS_SOMEIP_00008)
This can be used to handle all different application errors that might occur in the server.
In addition, problems with the communication medium or intermediate components
(e.g. switches) may occur, which have to be handled e.g. by means of reliable trans-
port.
All messages have a return code field in their header. (See chapter 4.1.1)
[PRS_SOMEIP_00904] d Only responses (Response Messages (message type 0x80)
and Error Messages (message type 0x81) shall use the return code field to carry a
return code to the request (Message Type 0x00) they answer. c(RS_SOMEIP_00008)
[PRS_SOMEIP_00905] d All other messages than 0x80 and 0x81 (see Chap-
ter 4.1.1.6) shall set this field to 0x00. c(RS_SOMEIP_00008)
4.2.6.1 Return Code
[PRS_SOMEIP_00187] d The return code shall be UINT8. c(RS_SOMEIP_00008)

[PRS_SOMEIP_00191] d Currently defined Return Codes are shown in Table 4.11

c(RS_SOMEIP_00008)
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 (inter-
nal error code only).
0x06 E_TIMEOUT A timeout occurred (internal error code only).
0x07 E_WRONG_PROTOCOL_ Version of SOME/IP protocol not supported
VERSION
0x08 E_WRONG_INTERFACE_ Interface version mismatch
VERSION
0x09 E_MALFORMED_MESSAGE Deserialization error, so that payload cannot be de-
serialized.
0x0a E_WRONG_MESSAGE_TYPE An unexpected message type was received (e.g.
REQUEST_NO_RETURN for a method defined as
REQUEST.)
0x0b - RESERVED Reserved for generic SOME/IP errors. These errors
0x1f will be specified in future versions of this document.
0x20 - RESERVED Reserved for specific errors of services and meth-
0x5E ods. These errors are specified by the interface
specification.
Table 4.11: Return Codes
Generation and handling of return codes shall be configurable.

[PRS_SOMEIP_00539] d A SOME/IP error message (i.e. return code 0x01 - 0x1f)
shall not be answered with an error message. c(RS_SOMEIP_00008)
4.2.6.2 Error Message
For more flexible error handling, SOME/IP allows a different message layout specific
for Error Messages instead of using the message layout of Response Messages.
The recommended layout for the exception message is the following:
• Union of specific exceptions. At least a generic exception without fields needs to
exist.
• Dynamic Length String for exception description.
Rationale: The union gives the flexibility to add new exceptions in the future in a type-
safe manner. The string is used to transport human readable exception descriptions to
ease testing and debugging.

[PRS_SOMEIP_00188] d The receiver of a SOME/IP message shall not return an error

message for events/notifications. c(RS_SOMEIP_00008)
message for fire&forget methods. c(RS_SOMEIP_00008)
message for events/notifications and fire&forget methods if the Message Type is set
incorrectly to Request or Response. c(RS_SOMEIP_00008)
[PRS_SOMEIP_00190] d For Request/Response methods the error message shall
copy over the fields of the SOME/IP header (i.e. Message ID, Request ID, and In-
terface Version) but not the payload. In addition Message Type and Return Code have
to be set to the appropriate values. c(RS_SOMEIP_00008)
4.2.6.3 Error Processing Overview
[PRS_SOMEIP_00576] d Error handling shall be based on the message type received

(e.g. only methods can be answered with a return code) and shall be checked in a
defined order of [PRS_SOMEIP_00195]. c(RS_SOMEIP_00008)
[PRS_SOMEIP_00910] d For SOME/IP messages received over UDP, the following
shall be checked:
• The UDP datagram size shall be at least 16 Bytes (minimum size of a SOME/IP
message)
• The value of the length field shall be less than or equal to the remaining bytes in
the UDP datagram payload
If one check fails, a malformed error shall be issued. c(RS_SOMEIP_00008)
SOME/IP messages shall be checked based on the error processing as shown
in Figure 4.13. This does not include the application based error handling but

just covers the error handling in messaging and RPC. c(RS_SOMEIP_00008)
Figure 4.13: Message Validation and Error Handling in SOME/IP
[PRS_SOMEIP_00614] d When one of the errors specified in [PRS_SOMEIP_00195]

occurs while receiving SOME/IP messages over TCP, the receiver shall check the TCP
connection and shall restart the TCP connection if needed. c(RS_SOMEIP_00008)
Rational:
Checking the TCP connection might include the following:
• Checking whether data is received for e.g. other Eventgroups.
• Sending out a Magic Cookie message and waiting for the TCP ACK.
• Reestablishing the TCP connection

4.2.6.4 Communication Errors and Handling of Communication Errors
When considering the transport of RPC messages different reliability semantics exist:
• Maybe — the message might reach the communication partner
• At least once — the message reaches the communication partner at least once
• Exactly once — the message reaches the communication partner exactly once
When using the above terms, in regard to Request/Response the term applies to both
messages (i.e. request and response or error).
While different implementations may implement different approaches, SOME/IP cur-
rently achieves "maybe" reliability when using the UDP binding and "exactly once" reli-
ability when using the TCP binding. Further error handling is left to the application.
For "maybe" reliability, only a single timeout is needed, when using request/response
communication in combination of UDP as transport protocol. Figure 4.14 shows the
state machines for "maybe" reliability. The client’s SOME/IP implementation has to
wait for the response for a specified timeout. If the timeout occurs SOME/IP shall
signal E_TIMEOUT to the client application.
Client
/ sendReq rspReceived
waitingForResponse
rspTimeout
Error: NoResponse
Server
reqReceived / sendRsp
processing
Figure 4.14: State Machines for Reliability "Maybe"
For "exactly once" reliability the TCP binding may be used, since TCP was defined to
allow for reliable communication.

5 Configuration Parameters
Configuration Parameters are not handled and described in this document.

6 Protocol usage and guidelines
6.1 Choosing the transport protocol

SOME/IP supports 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 a reliable communication. TCP not only handles bit errors but
also segmentation, loss, duplication, reordering, and network congestion.
Inside a vehicle many applications requires very short timeout to react quickly. These
requirements are better met using UDP because the application itself can handle the
unlikely event of errors. For example, in use cases with cyclic data it is often the best
approach to just wait for the next data transmission instead of trying to repair the last
one. The major disadvantage of UDP is that it does not handle segmentation. Hence,
only being able to transport smaller chunks of data.
Guideline:
• Use TCP only if very large chunks of data need to be transported (> 1400 Bytes)
and no hard latency requirements in the case of errors exists
• Use UDP if very hard latency requirements (<100ms) in case of errors is needed
• Use UDP together with SOME/IP-TP if very large chunks of data need to be
transported (> 1400 Bytes) and hard latency requirements in the case of errors
exists
• Try using external transport or transfer mechanisms (Network File System, APIX
link, 1722, ...) when they are more suited for the use case. In this case SOME/IP
can transport a file handle or a comparable identifier. This gives the designer
additional freedom (e.g. in regard to caching).
The transport protocol used is specified by the interface specification on a per-message
basis. Methods, Events, and Fields should commonly only use a single transport pro-
tocol.
6.2 Transporting CAN and FlexRay Frames

SOME/IP should allow to tunnel CAN and FlexRay frames. However, the Message ID
space needs to be coordinated between both use cases. The full SOME/IP Header
shall be used for transporting/tunneling CAN/FlexRay.

6.3 Insert Padding for structs

If padding is nceessary, the designer of the interface shall Insert reserved/padding ele-
ments in the the definition of the data types if needed for alignment, since the SOME/IP
implementation shall not automatically add such padding.

7 References
Bibliography
[1] Glossary
AUTOSAR_TR_Glossary


Autosar Prs Someipprotocol

Uploaded by

Copyright:

Available Formats

Autosar Prs Someipprotocol

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Autosar Prs Someipprotocol

Uploaded by

Copyright:

Available Formats

SOME/IP Protocol Specification

AUTOSAR FO Release 1.0.0

Document Title SOME/IP Protocol Specification

Document Status Final

Document Change History

1 of 50 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

Advice for users

AUTOSAR specifications may contain exemplary items (exemplary reference models,

2 of 50 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

3 of 50 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

4.2.4 Notification Events . . . . . . . . . . . . . . . . . . . . . . . . 40

6 Protocol usage and guidelines 48

4 of 50 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

1 Introduction and overview

1.1 Protocol purpose and objectives

1.2 Applicability of the protocol

1.2.1 Constraints and assumptions

5 of 50 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

1.4 Document Structure

6 of 50 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

• Rules that govern the RPC for SOME/IP

7 of 50 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

2.1 Requirements Traceability

Feature Description Satisfied by

8 of 50 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

[RS_SOMEIP_00010] SOME/IP protocol shall support [PRS_SOMEIP_00137]

9 of 50 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

[RS_SOMEIP_00011] SOME/IP protocol shall support [PRS_SOMEIP_00162]

10 of 50 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

[RS_SOMEIP_00027] SOME/IP protocol shall define the [PRS_SOMEIP_00030]

11 of 50 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

[RS_SOMEIP_00034] SOME/IP protocol shall support [PRS_SOMEIP_00118]

12 of 50 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

3 Acronyms and Abbreviations

Abbreviation / Acronym: Description:

Table 3.1: Acronyms and Abbreviations

13 of 50 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

4.1 Specification of SOME/IP on wire-format (Serialization)

14 of 50 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

The structure of header layout is as shown in the Figure 4.1. c(RS_SOMEIP_00027)

Figure 4.1: SOME/IP Header Format

[PRS_SOMEIP_00031] d For interoperability reasons the header layout shall be identi-

4.1.1.1 Message ID [32 Bit]

[PRS_SOMEIP_00034] d The Message ID shall be a 32 Bit identifier that is used

Service ID [16 Bit] 0 [1 Bit] Method ID [last 15 Bit]

Table 4.1: Structure of ID

4.1.1.2 Length [32 Bit]

15 of 50 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

4.1.1.3 Request ID [32 Bit]

4.1.1.3.1 Structure of the Request ID

[PRS_SOMEIP_00046] d In AUTOSAR the Request ID shall be constructed of the

Client ID [16 Bits] Session ID [16 Bits]

Table 4.2: Structure of Request ID

Client ID Prefix [8 Client ID [8 Bits] Session ID [16 Bits]

16 of 50 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

Table 4.3: Example of Client ID

[PRS_SOMEIP_00533] d Request/Response methods shall use session handling

4.1.1.4 Protocol Version [8 Bit]

[PRS_SOMEIP_00052] d Protocol Version shall be an 8 Bit field containing the

4.1.1.5 Interface Version [8 Bit]