SOME/IP Protocol Specification

AUTOSAR FO R22-11

Document Title SOME/IP Protocol Specification

Document Owner AUTOSAR

Document Responsibility AUTOSAR

Document Identification No 696

Document Status published

Part of AUTOSAR Standard Foundation

Part of Standard Release R22-11

Document Change History

Date Release Changed by

Description

2022-11-24 R22-11

AUTOSAR

Release

Management

• Clarification of SOME/IP-TP

segmentation

• Removed

implementsSOMEIPStringHandling

• [PRS_SOMEIP_00300] extended by

uint64

• Corrected serialization with BOM in

[PRS_SOMEIP_00374]

• Corrected multiple Bugs in

[PRS_SOMEIP_00043],

[PRS_SOMEIP_00739],

[PRS_SOMEIP_00043],

[PRS_SOMEIP_00241],

[PRS_SOMEIP_00101],

[PRS_SOMEIP_00942] and

[PRS_SOMEIP_00922]

• Added [PRS_SOMEIP_00245] to

correct mismatch in size of

Method-ID

• Editorial Changes

1 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

2021-11-25 R21-11

AUTOSAR

Release

Management

• Added Restriction of Server

Connection from Clients

• Added Restriction of Client

Connection to Server

• Clarification on String Handling in

SOME/IP

• SOME/IP Header shall be encoded

in network byte order

• Editorial Changes

2020-11-30 R20-11

AUTOSAR

Release

Management

• Removed Draft Status from TLV

Requirements

• Fixed discrepancies between SWS

and PRS

• Clarified usage of length field

• Restricted alignment of variable

length arrays to 8, 16, 32, 64, 128 or

256 Bits

• Editorial Changes

2019-11-28 R19-11

AUTOSAR

Release

Management

• Added

– Support for unit64 / sint64

– Error-Codes for E2E-Protection

• Clarify

– Serialization of fixed length

array data

– Support for Data Accumulation

feature

– Contradicting requirements

• Introduce

implementsLegacyStringSerialization

tag (as successor of

implementsSOMEIPStringHandling)

• Editorial Changes

• Changed Document Status from

Final to published

2019-03-29 1.5.1

AUTOSAR

Release

Management

• No content changes

2018-10-31 1.5.0

AUTOSAR

Release

Management

• Backward-incompatibility statement

removed

• Some statements improved

2018-03-29 1.4.0

AUTOSAR

Release

Management

• Improved traceability

2 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

2017-12-08 1.3.0

AUTOSAR

Release

Management

• No content changes

2017-10-27 1.2.0

AUTOSAR

Release

Management

• Editorial changes

2017-03-31 1.1.0

AUTOSAR

Release

Management

• Serialization of Structured Datatypes

and Arguments with Identifier and

optional members

2016-11-30 1.0.0

AUTOSAR

Release

Management

Initial Release

3 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

Disclaimer

This work (specification and/or software implementation) 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 work.

The material contained in this work is protected by copyright and other types of intel-

lectual property rights. The commercial exploitation of the material contained in this

work requires a license to such intellectual property rights.

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

may be utilized or reproduced, in any form or by any means, without permission in

writing from the publisher.

The work has been developed for automotive applications only. It has neither been

developed, nor tested for non-automotive applications.

The word AUTOSAR and the AUTOSAR logo are registered trademarks.

4 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

Contents

1 Introduction and overview 7

1.1 Protocol purpose and objectives . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Applicability of the protocol . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2.1 Constraints and assumptions . . . . . . . . . . . . . . . . . . 7

1.2.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4 Document Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Protocol Requirements 9

2.1 Requirements Traceability . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Acronyms and Abbreviations 17

4 Protocol specification 19

4.1 Specification of SOME/IP Message Format (Serialization) . . . . . . . 19

4.1.1 Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1.2 Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1.2.1 Message ID [32 Bit] . . . . . . . . . . . . . . . . . . 21

4.1.2.2 Method ID [16 Bit] . . . . . . . . . . . . . . . . . . . 21

4.1.2.3 Length [32 Bit] . . . . . . . . . . . . . . . . . . . . . 22

4.1.2.4 Request ID [32 Bit] . . . . . . . . . . . . . . . . . . . 22

4.1.2.5 Protocol Version [8 Bit] . . . . . . . . . . . . . . . . . 23

4.1.2.6 Interface Version [8 Bit] . . . . . . . . . . . . . . . . 24

4.1.2.7 Message Type [8 Bit] . . . . . . . . . . . . . . . . . . 24

4.1.2.8 Return Code [8 Bit] . . . . . . . . . . . . . . . . . . . 25

4.1.2.9 Payload [variable size] . . . . . . . . . . . . . . . . . 25

4.1.3 Endianess . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1.4 Serialization of Data Structures . . . . . . . . . . . . . . . . . 26

4.1.4.1 Basic Datatypes . . . . . . . . . . . . . . . . . . . . 28

4.1.4.2 Structured Datatypes (structs) . . . . . . . . . . . . . 28

4.1.4.3 Structured Datatypes and Arguments with Identifier

and optional members . . . . . . . . . . . . . . . . . 29

4.1.4.4 Strings . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1.4.5 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1.4.6 Enumeration . . . . . . . . . . . . . . . . . . . . . . 43

4.1.4.7 Bitfield . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.4.8 Union / Variant . . . . . . . . . . . . . . . . . . . . . 43

4.2 Specification of SOME/IP Protocol . . . . . . . . . . . . . . . . . . . . 45

4.2.1 Transport Protocol Bindings . . . . . . . . . . . . . . . . . . . 45

4.2.1.1 UDP Binding . . . . . . . . . . . . . . . . . . . . . . 46

4.2.1.2 TCP Binding . . . . . . . . . . . . . . . . . . . . . . 47

4.2.1.3 Multiple Service-Instances . . . . . . . . . . . . . . . 49

4.2.1.4 Transporting large SOME/IP messages of UDP

(SOME/IP-TP) . . . . . . . . . . . . . . . . . . . . . 50

5 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

4.2.2 Request/Response Communication . . . . . . . . . . . . . . 56

4.2.3 Fire&Forget Communication . . . . . . . . . . . . . . . . . . 57

4.2.4 Notification Events . . . . . . . . . . . . . . . . . . . . . . . . 58

4.2.4.1 Strategy for sending notifications . . . . . . . . . . . 58

4.2.5 Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.2.6 Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.2.6.1 Return Code . . . . . . . . . . . . . . . . . . . . . . 60

4.2.6.2 Error Message . . . . . . . . . . . . . . . . . . . . . 61

4.2.6.3 Error Processing Overview . . . . . . . . . . . . . . 62

4.2.6.4 Communication Errors and Handling of Communica-

tion Errors . . . . . . . . . . . . . . . . . . . . . . . . 64

4.3 Compatibility Rules for Interface Version . . . . . . . . . . . . . . . . . 64

5 Configuration Parameters 68

6 Protocol usage and guidelines 69

6.1 Choosing the transport protocol . . . . . . . . . . . . . . . . . . . . . . 69

6.2 Transporting CAN and FlexRay Frames . . . . . . . . . . . . . . . . . . 69

6.3 Insert Padding for structs . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.4 Security Considerations for SOME/IP . . . . . . . . . . . . . . . . . . . 70

6 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

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

The "Support for ser ialization of extensible data structs" has been introduced - which

SOME/IP serializers based on AUTOSAR Foundation Standard 1.0.0 (AUTOSAR

Classic Standard 4.3.0) cannot process. To indicate this interoperability issue

7 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIP_00220] requires to increase the major interface version of the respec-

tive serialized data.

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

8 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

2 Protocol Requirements

2.1 Requirements Traceability

Feature Description Satisfied by

[RS_SOMEIP_00002] SOME/IP protocol shall provide

service-based communication

[PRS_SOMEIP_00703]

[PRS_SOMEIP_00909]

[RS_SOMEIP_00003] SOME/IP protocol shall provide

support of multiple versions of a

service interface

[PRS_SOMEIP_00053]

[PRS_SOMEIP_00937]

[PRS_SOMEIP_00938]

[RS_SOMEIP_00004] SOME/IP protocol shall support

event communication

[PRS_SOMEIP_00925]

[PRS_SOMEIP_00926]

[RS_SOMEIP_00005] SOME/IP protocol shall support

different strategies for event

communication

[PRS_SOMEIP_00183]

[RS_SOMEIP_00006] SOME/IP protocol shall support

uni-directional RPC communication

[PRS_SOMEIP_00171]

[PRS_SOMEIP_00924]

[RS_SOMEIP_00007] SOME/IP protocol shall support

bi-directional RPC communication

[PRS_SOMEIP_00920]

[PRS_SOMEIP_00921]

[PRS_SOMEIP_00922]

[PRS_SOMEIP_00923]

[PRS_SOMEIP_00927]

[PRS_SOMEIP_00928]

[RS_SOMEIP_00008] SOME/IP protocol shall support

error handling of RPC

communication

[PRS_SOMEIP_00055]

[PRS_SOMEIP_00058]

[PRS_SOMEIP_00187]

[PRS_SOMEIP_00188]

[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_00701]

[PRS_SOMEIP_00901]

[PRS_SOMEIP_00902]

[PRS_SOMEIP_00903]

[PRS_SOMEIP_00904]

[PRS_SOMEIP_00905]

[PRS_SOMEIP_00910]

[RS_SOMEIP_00009] SOME/IP protocol shall support

field communication

[PRS_SOMEIP_00179]

[PRS_SOMEIP_00180]

[PRS_SOMEIP_00181]

[PRS_SOMEIP_00182]

[PRS_SOMEIP_00183]

[PRS_SOMEIP_00909]

9 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

[RS_SOMEIP_00010] SOME/IP protocol shall support

different transport protocols

underneath

[PRS_SOMEIP_00137]

[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_00749]

[PRS_SOMEIP_00750]

[PRS_SOMEIP_00751]

[PRS_SOMEIP_00752]

[PRS_SOMEIP_00753]

[PRS_SOMEIP_00754]

[PRS_SOMEIP_00940]

[PRS_SOMEIP_00942]

[PRS_SOMEIP_00943]

[RS_SOMEIP_00011] SOME/IP protocol shall support

messages of different lengths

[PRS_SOMEIP_00722]

10 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

[RS_SOMEIP_00012] SOME/IP protocol shall support

session handling

[PRS_SOMEIP_00521]

[PRS_SOMEIP_00533]

[PRS_SOMEIP_00720]

[PRS_SOMEIP_00721]

[PRS_SOMEIP_00739]

[PRS_SOMEIP_00935]

[PRS_SOMEIP_00936]

[RS_SOMEIP_00014] SOME/IP protocol shall support

handling of protocol errors on

receiver side

[PRS_SOMEIP_00195]

[PRS_SOMEIP_00576]

[PRS_SOMEIP_00614]

[PRS_SOMEIP_00910]

[RS_SOMEIP_00015] SOME/IP protocol shall support

multiple instances of a service

[PRS_SOMEIP_00138]

[PRS_SOMEIP_00162]

[PRS_SOMEIP_00163]

[RS_SOMEIP_00016] SOME/IP protocol shall support

combining multiple RPC methods,

events and fields in one ser vice

[PRS_SOMEIP_00245]

[PRS_SOMEIP_00366]

[RS_SOMEIP_00017] SOME/IP protocol shall support

grouping events into eventgroups

[PRS_SOMEIP_00365]

[PRS_SOMEIP_00366]

[RS_SOMEIP_00018] SOME/IP protocol shall support

grouping fields in eventgroups

[PRS_SOMEIP_00366]

[RS_SOMEIP_00021] SOME/IP protocol shall identify

RPC methods of services using

unique identifiers

[PRS_SOMEIP_00034]

[RS_SOMEIP_00022] SOME/IP protocol shall identify

events of ser vices using unique

identifiers

[PRS_SOMEIP_00034]

[RS_SOMEIP_00023] SOME/IP protocol shall identify

event groups of services using

unique identifiers

[PRS_SOMEIP_00034]

[RS_SOMEIP_00024] SOME/IP protocol shall define

reserved identifiers

[PRS_SOMEIP_00191]

[PRS_SOMEIP_00907]

[RS_SOMEIP_00025] SOME/IP protocol shall support the

identification of callers of an RPC

using unique identifiers

[PRS_SOMEIP_00043]

[PRS_SOMEIP_00044]

[PRS_SOMEIP_00532]

[PRS_SOMEIP_00702]

[PRS_SOMEIP_00703]

[RS_SOMEIP_00026] SOME/IP protocol shall define the

endianness of header and payload

[PRS_SOMEIP_00368]

[PRS_SOMEIP_00369]

11 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

[RS_SOMEIP_00027] SOME/IP protocol shall define the

header layout of messages

[PRS_SOMEIP_00030]

[PRS_SOMEIP_00031]

[PRS_SOMEIP_00034]

[PRS_SOMEIP_00042]

[PRS_SOMEIP_00043]

[PRS_SOMEIP_00046]

[PRS_SOMEIP_00050]

[PRS_SOMEIP_00051]

[PRS_SOMEIP_00052]

[PRS_SOMEIP_00053]

[PRS_SOMEIP_00055]

[PRS_SOMEIP_00058]

[PRS_SOMEIP_00141]

[PRS_SOMEIP_00245]

[PRS_SOMEIP_00365]

[PRS_SOMEIP_00366]

[PRS_SOMEIP_00367]

[PRS_SOMEIP_00521]

[PRS_SOMEIP_00532]

[PRS_SOMEIP_00533]

[PRS_SOMEIP_00701]

[PRS_SOMEIP_00702]

[PRS_SOMEIP_00703]

[PRS_SOMEIP_00704]

[PRS_SOMEIP_00723]

[PRS_SOMEIP_00724]

[PRS_SOMEIP_00725]

[PRS_SOMEIP_00726]

[PRS_SOMEIP_00727]

[PRS_SOMEIP_00728]

[PRS_SOMEIP_00739]

[PRS_SOMEIP_00931]

[PRS_SOMEIP_00932]

[PRS_SOMEIP_00933]

[PRS_SOMEIP_00934]

[PRS_SOMEIP_00935]

[PRS_SOMEIP_00936]

[PRS_SOMEIP_00940]

[PRS_SOMEIP_00941]

12 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

[RS_SOMEIP_00028] SOME/IP protocol shall specify the

serialization algorithm for data

[PRS_SOMEIP_00101]

[PRS_SOMEIP_00130]

[PRS_SOMEIP_00210]

[PRS_SOMEIP_00211]

[PRS_SOMEIP_00212]

[PRS_SOMEIP_00213]

[PRS_SOMEIP_00214]

[PRS_SOMEIP_00216]

[PRS_SOMEIP_00220]

[PRS_SOMEIP_00569]

[PRS_SOMEIP_00611]

[PRS_SOMEIP_00612]

[PRS_SOMEIP_00613]

[PRS_SOMEIP_00712]

[PRS_SOMEIP_00921]

[PRS_SOMEIP_00923]

[RS_SOMEIP_00029] SOME/IP protocol shall specify how

data in the payload are aligned

[PRS_SOMEIP_00222]

[PRS_SOMEIP_00569]

[PRS_SOMEIP_00611]

[PRS_SOMEIP_00612]

[PRS_SOMEIP_00613]

[PRS_SOMEIP_00730]

[RS_SOMEIP_00030] SOME/IP protocol shall support

transporting integer data types

[PRS_SOMEIP_00065]

[PRS_SOMEIP_00300]

[PRS_SOMEIP_00615]

[PRS_SOMEIP_00705]

[RS_SOMEIP_00031] SOME/IP protocol shall support

transporting boolean data type

[PRS_SOMEIP_00065]

[PRS_SOMEIP_00615]

[RS_SOMEIP_00032] SOME/IP protocol shall support

transporting float data types

[PRS_SOMEIP_00065]

[PRS_SOMEIP_00615]

[RS_SOMEIP_00033] SOME/IP protocol shall support

transporting structured data types

[PRS_SOMEIP_00077]

[PRS_SOMEIP_00079]

[PRS_SOMEIP_00300]

[PRS_SOMEIP_00370]

[PRS_SOMEIP_00371]

[PRS_SOMEIP_00705]

[PRS_SOMEIP_00712]

[PRS_SOMEIP_00900]

[RS_SOMEIP_00034] SOME/IP protocol shall support

transporting union data types

[PRS_SOMEIP_00118]

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

13 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

[RS_SOMEIP_00035] SOME/IP protocol shall support

transporting one-dimensional and

multi-dimensional array data types

[PRS_SOMEIP_00099]

[PRS_SOMEIP_00101]

[RS_SOMEIP_00036] SOME/IP protocol shall support

transporting array data types with a

fixed length

[PRS_SOMEIP_00099]

[PRS_SOMEIP_00101]

[PRS_SOMEIP_00917]

[PRS_SOMEIP_00918]

[PRS_SOMEIP_00944]

[RS_SOMEIP_00037] SOME/IP protocol shall support

transporting array data types with

flexible length

[PRS_SOMEIP_00107]

[PRS_SOMEIP_00114]

[PRS_SOMEIP_00375]

[PRS_SOMEIP_00376]

[PRS_SOMEIP_00377]

[PRS_SOMEIP_00919]

[PRS_SOMEIP_00945]

[RS_SOMEIP_00038] SOME/IP protocol shall support

transporting string types with a fixed

length

[PRS_SOMEIP_00084]

[PRS_SOMEIP_00085]

[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_00948]

[RS_SOMEIP_00039] SOME/IP protocol shall support

transporting str ing data types with

flexible length

[PRS_SOMEIP_00089]

[PRS_SOMEIP_00090]

[PRS_SOMEIP_00091]

[PRS_SOMEIP_00092]

[PRS_SOMEIP_00093]

[PRS_SOMEIP_00094]

[PRS_SOMEIP_00095]

[PRS_SOMEIP_00914]

[RS_SOMEIP_00040] SOME/IP protocol shall support

providing the length of a serialized

data element in the payload

[PRS_SOMEIP_00042]

[PRS_SOMEIP_00079]

[PRS_SOMEIP_00094]

[PRS_SOMEIP_00208]

[PRS_SOMEIP_00221]

[PRS_SOMEIP_00370]

[PRS_SOMEIP_00945]

[RS_SOMEIP_00041] SOME/IP protocol shall provide

support of multiple versions of the

protocol

[PRS_SOMEIP_00050]

[PRS_SOMEIP_00051]

[PRS_SOMEIP_00052]

[RS_SOMEIP_00042] SOME/IP protocol shall support

unicast and multicast based event

communication

[PRS_SOMEIP_00930]

14 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

[RS_SOMEIP_00050] SOME/IP protocol shall support

serialization of extensible data

structs

[PRS_SOMEIP_00201]

[PRS_SOMEIP_00202]

[PRS_SOMEIP_00203]

[PRS_SOMEIP_00204]

[PRS_SOMEIP_00205]

[PRS_SOMEIP_00206]

[PRS_SOMEIP_00208]

[PRS_SOMEIP_00210]

[PRS_SOMEIP_00211]

[PRS_SOMEIP_00212]

[PRS_SOMEIP_00213]

[PRS_SOMEIP_00214]

[PRS_SOMEIP_00216]

[PRS_SOMEIP_00217]

[PRS_SOMEIP_00218]

[PRS_SOMEIP_00220]

[PRS_SOMEIP_00221]

[PRS_SOMEIP_00222]

[PRS_SOMEIP_00223]

[PRS_SOMEIP_00224]

[PRS_SOMEIP_00225]

[PRS_SOMEIP_00226]

[PRS_SOMEIP_00227]

[PRS_SOMEIP_00228]

[PRS_SOMEIP_00229]

[PRS_SOMEIP_00230]

[PRS_SOMEIP_00231]

[PRS_SOMEIP_00241]

[PRS_SOMEIP_00242]

[PRS_SOMEIP_00243]

[PRS_SOMEIP_00244]

15 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

[RS_SOMEIP_00051] SOME/IP protocol shall provide

support for segmented transmission

of large data

[PRS_SOMEIP_00367]

[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_00749]

[PRS_SOMEIP_00750]

[PRS_SOMEIP_00751]

[PRS_SOMEIP_00752]

[PRS_SOMEIP_00753]

[PRS_SOMEIP_00754]

16 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

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:

Byte Order Mark

The byte order mark (BOM) is a Unicode character, U+FEFF byte

order mark (BOM), whose appearance as a magic number at the

start of a text stream is used to indicate the used encoding.

Method

A method, procedure, function, or subroutine that is called/in-

voked.

Parameters input, output, or input/output arguments of a method or an event

Remote Procedure Call (RPC)

A method call from one ECU to another that is transmitted using

messages

Request a message of the client to the server invoking a method

Response

a message of the server to the client transporting results of a

method invocation

Request/Response communica-

tion

a RPC that consists of request and response

Event

A uni-directional data transmission that is only invoked on

changes or cyclically and is sent from the producer of data to

the consumers.

Field

A field does represent a status and thus has an valid value at all

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.

Notifier

Sends out event message with a new value on change of the

value of the field.

Service

A logical combination of zero or more methods, zero or more

events, and zero or more fields.

Service Interface

the formal specification of the service including its methods,

events, and fields

Eventgroup

A logical grouping of events and notification events of fields inside

a service in order to allow subscription

Service Instance

Implementation of a service, which can exist more than once in

the vehicle and more than once on an ECU

Server

The ECU offering a service instance shall be called server in the

context of this service instance.

Client

The ECU using the service instance of a server shall be called

client in the context of this service instance.

Fire and Forget Requests without response message are called fire&forget.

User Datagram Protocol

A standard network protocol using a simple connectionless com-

munication model.

Union A data structure that dynamically assumes different data types.

non-extensible (standard) struct

A struct which is serialized without tags. At most, new members

can be added in a compatible way at the end of the struct and

optional members are not possible.

17 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

Abbreviation / Acronym: Description:

extensible struct

A struct which is serialized with tags. New members can be

added in a compatible way at arbitrary positions and optional

members are possible.

Table 3.1: Acronyms and Abbreviations

18 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

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 ser vice 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 subscriber 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 subscr iber to explicitly 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 events are

only sent on change, the notifier of a field additionally sends the data directly after

subscription.

4.1 Specification of SOME/IP Message 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 Limitation

Reordering of out-of-order segments of a SOME/IP message is not supported.

4.1.2 Header

[PRS_SOMEIP_00030] dThe structure of header layout shall consist of

• Message ID (Service ID/Method ID) [32 Bits]

• Length [32 Bits]

• Request ID (Client ID/Session ID) [32 Bits]

• Protocol Version [8Bits]

19 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

• Interface Version [8 Bits]

• Message Type [8 Bits]

• Return Code [8 Bits]

c(RS_SOMEIP_00027)

[PRS_SOMEIP_00030] is shown in the Figure 4.1.

Figure 4.1: SOME/IP Header Format

[PRS_SOMEIP_00941] dIn case of E2E communication protection being applied, the

E2E header is placed after Return Code, depending on the chosen Offset value for

the E2E header. The default Offset value is 64 bit, which puts the E2E header exactly

between Return Code and Payload.c(RS_SOMEIP_00027)

[PRS_SOMEIP_00941] ss shown in the Figure 4.2.

Figure 4.2: SOME/IP Header and E2E header Format

20 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIP_00031] dFor 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.2.1 Message ID [32 Bit]

[PRS_SOMEIP_00034] dThe 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_00021, RS_SOMEIP_00022, RS_SOMEIP_00023, RS_SOMEIP_-

00027)

Note: The assignment of the Message ID is up to the user / system designer. However,

the Message ID is assumed be unique for the whole system (i.e. the vehicle).

4.1.2.2 Method ID [16 Bit]

[PRS_SOMEIP_00245] dThe Message ID header field shall be structured into a 16

Bit Service ID header field (to distinguish up to 2

services) and a 16 bit Method ID

header field to distinguish up to 2

service elements (namely methods and/or events).

This structuring of the Message ID header field is illustrated as shown in Table 4.1.c

(RS_SOMEIP_00016, RS_SOMEIP_00027)

Note: It is common practise and recommended to split the ID space of the Method ID

between Methods and Events/Notifications. Methods would be in the range 0x0000-

0x7FFF (first bit of Method-ID is 0) and Events/Notifications would use the range

0x8000-0x8FFF (first bit of the Method-ID is 1).

Service ID [16 Bit] Method ID [16

Bit]

Table 4.1: Structure of the Message ID header field

Eventgroup is a logical grouping of events and notification events of fields inside a

service in order to allow subscription.

[PRS_SOMEIP_00365] dA SOME/IP Eventgroup shall at least contain one event.c

(RS_SOMEIP_00027, RS_SOMEIP_00017)

[PRS_SOMEIP_00366] dEvents as well as field notifiers shall be mapped to at

least one SOME/IP Eventgroup.c(RS_SOMEIP_00027, RS_SOMEIP_00016, RS_-

SOMEIP_00017, RS_SOMEIP_00018)

21 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

4.1.2.3 Length [32 Bit]

[PRS_SOMEIP_00042] dLength field shall contain the length in Byte starting from Re-

quest ID/Client ID until the end of the SOME/IP message.c(RS_SOMEIP_00027, RS_-

SOMEIP_00040)

4.1.2.4 Request ID [32 Bit]

The Request ID allows a server and client to differentiate multiple parallel uses of the

same method, getter or setter.

[PRS_SOMEIP_00043] dThe Request ID shall be unique for a request-response pair to

differentiate between multiple calls of the same method.c(RS_SOMEIP_00025, RS_-

SOMEIP_00027)

[PRS_SOMEIP_00704] dWhen 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 client to map a response to the issued request even with more than one

request outstanding.

[PRS_SOMEIP_00044] dRequest IDs must not be reused until the response has ar-

rived or is not expected to arrive anymore (timeout).c(RS_SOMEIP_00025)

Structure of the Request ID

[PRS_SOMEIP_00046] dIn 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] dThe Client ID is the unique identifier for the calling client in-

side the ECU. The Client ID allows an ECU to differentiate calls from multiple clients to

the same method.c(RS_SOMEIP_00025, RS_SOMEIP_00027)

22 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIP_00703] dThe Session ID is a unique identifier that allows to distinguish

sequential messages or requests originating from the same sender from each other.c

(RS_SOMEIP_00002, RS_SOMEIP_00025, RS_SOMEIP_00027)

[PRS_SOMEIP_00532] dThe 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(RS_SOMEIP_00025, RS_SOMEIP_00027)

For example:

Client ID Prefix [8

Bits]

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

Table 4.3: Example of Client ID

[PRS_SOMEIP_00932] dIn case Session Handling is not active, the Session ID shall

be set to 0x00.c(RS_SOMEIP_00027)

[PRS_SOMEIP_00933] dIn case Session Handling is active, the Session ID shall be

set to a value within the range [0x1, 0xFFFF].c(RS_SOMEIP_00027)

[PRS_SOMEIP_00934] dIn case Session Handling is active, the Session ID shall be in-

cremented according to the respective use case (detailed information about dedicated

use cases is contained in separate specification items (e.g., [PRS_SOMEIP_00533]).c

(RS_SOMEIP_00027)

[PRS_SOMEIP_00533] dRequest/Response methods shall use session handling with

Session IDs. Session ID should be incremented after each call.c(RS_SOMEIP_00012,

RS_SOMEIP_00027)

[PRS_SOMEIP_00521] dWhen the Session ID reaches 0xFFFF, it shall wrap around

and start again with 0x01c(RS_SOMEIP_00012, RS_SOMEIP_00027)

[PRS_SOMEIP_00739] dFor request/response methods, a client has to ignore a re-

sponse if the Session ID of the response does not match the Session ID of the requestc

(RS_SOMEIP_00012, RS_SOMEIP_00027)

[PRS_SOMEIP_00935] dFor notification messages, a receiver shall ignore the Session

ID in case Session Handling is not active.c(RS_SOMEIP_00012, RS_SOMEIP_00027)

[PRS_SOMEIP_00936] dFor notification messages, a receiver shall treat the Session

ID according to the respective use case (detailed information about dedicated use

cases is contained in separate specification items (e.g., [PRS_SOMEIP_00741]) in

case Session Handling is active.c(RS_SOMEIP_00012, RS_SOMEIP_00027)

4.1.2.5 Protocol Version [8 Bit]

The Protocol Version identifies the used SOME/IP Header format (not including the

Payload format).

23 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

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

SOME/IP protocol version.c(RS_SOMEIP_00027, RS_SOMEIP_00041)

[PRS_SOMEIP_00050] dThe Protocol Version shall be increased, for all incompatible

changes in the SOME/IP header. A change is incompatible if a receiver that is based

on an older Protocol Version would not discard the message and process it incorrectly.c

(RS_SOMEIP_00027, RS_SOMEIP_00041)

Note:

Message processing and error handling is defined in chapter 4.2.6.3 (error processing

overview)

Note:

The Protocol Version itself is part of the SOME/IP Header, therefore the position of the

protocol version in the header shall not be changed.

Note:

The Protocol Version shall not be increased for changes that only affect the Payload

format.

[PRS_SOMEIP_00051] dThe Protocol Version shall be 1.c(RS_SOMEIP_00027, RS_-

SOMEIP_00041)

4.1.2.6 Interface Version [8 Bit]

[PRS_SOMEIP_00053] dInterface Version shall be an 8 Bit field that contains the Major

Version of the Service Interface.c(RS_SOMEIP_00003, RS_SOMEIP_00027)

4.1.2.7 Message Type [8 Bit]

[PRS_SOMEIP_00055] dThe 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_00008, 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

24 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

0xa0 TP_RESPONSE The TP response message

0xa1 TP_ERROR The TP response containing an error

Table 4.4: Message Types

[PRS_SOMEIP_00701] dRegular 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_00008, 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] dThe 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.2.8 Return Code [8 Bit]

[PRS_SOMEIP_00058] dThe 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.5c(RS_SOMEIP_00008, 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 specific Message Types

4.1.2.9 Payload [variable size]

In the payload field the parameters are carried. The serialization of the parameters will

be specified in the following section.

25 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

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

[PRS_SOMEIP_00368] dAll SOME/IP Header Fields shall be encoded in network byte

order (big endian).c(RS_SOMEIP_00026)

[PRS_SOMEIP_00369] dThe 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] dAlignment of data shall be realized by inserting padding ele-

ments after the variable size data if the variable size data is not the last element in the

serialized data stream.c(RS_SOMEIP_00028, RS_SOMEIP_00029)

Note:

Please note that the padding value is not defined.

26 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

Figure 4.3: SOME/IP Padding Example 01

Figure 4.4: SOME/IP Padding Example 02

[PRS_SOMEIP_00569] dAlignment shall always be calculated from start of SOME/IP

message.c(RS_SOMEIP_00028, RS_SOMEIP_00029)

[PRS_SOMEIP_00612] dThere shall be no padding behind fixed length data elements

to ensure alignment of the following data.c(RS_SOMEIP_00028, RS_SOMEIP_00029)

27 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

Note:

If data behind fixed length data elements shall be padded, this has to be explicitly

considered in the data type definition.

[PRS_SOMEIP_00613] dThe alignment of data behind variable length data elements

shall be 8, 16, 32, 64, 128 or 256. Bits.c(RS_SOMEIP_00028, RS_SOMEIP_00029)

4.1.4.1 Basic Datatypes

[PRS_SOMEIP_00065] dThe following basic datatypes as shown in Table 4.6 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

uint16 unsigned Integer 16

uint32 unsigned Integer 32

uint64 unsigned Integer 64

sint8 signed Integer 8

sint16 signed Integer 16

sint32 signed Integer 32

sint64 signed Integer 64

float32 floating point number 32 IEEE 754 binary32 (Single Preci-

sion)

float64 floating point number 64 IEEE 754 binary64 (Double Preci-

sion)

Table 4.6: Supported basic Data Types

The Byte Order is specified for each parameter by configuration.

[PRS_SOMEIP_00615] dFor 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.

28 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

Example:

Struct_1

uint32 a

float32 b[2]

Struct_2 c

Struct_2

uint32 d

float32 e[2]

Struct_3 f

serialization

uint32 a

float32 b_1

float32 b_2

uint32 d

float32 e_1

float32 e_2

…

Figure 4.5: Serialization of Structs

[PRS_SOMEIP_00077] dThe SOME/IP implementation shall not automatically insert

dummy/padding data.c(RS_SOMEIP_00033)

[PRS_SOMEIP_00079] dAn 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, RS_-

SOMEIP_00040)

[PRS_SOMEIP_00370] dThe length field of the struct shall describe the number

of bytes this struct occupies for SOME/IP transport.c(RS_SOMEIP_00033, RS_-

SOMEIP_00040)

[PRS_SOMEIP_00371] dIf the length is greater than the length of the struct as spec-

ified in the data type definition only the bytes specified in the data type shall be inter-

preted and the other bytes shall be skipped based on the length field.c(RS_SOMEIP_-

00033)

[PRS_SOMEIP_00900] dIf 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] dThe serialization of structs shall follow the depth-first-

traversal of the structured data type.c(RS_SOMEIP_00028, RS_SOMEIP_00033)

4.1.4.3 Structured Datatypes and Arguments with Identifier and optional mem-

bers

To achieve enhanced forward and backward compatibility, an additional Data ID can

be added in front of struct members or method arguments. The receiver then can

skip unknown members/arguments, i.e. where the Data ID is unknown. New member-

29 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

s/arguments can be added at arbitrary positions when Data IDs are transferred in the

serialized byte stream.

Moreover, the usage of Data IDs allows describing structs and methods with optional

members/arguments. Whether a member/argument is optional or not, is defined in the

data definition.

Whether an optional member/argument is actually present in the struct/method or not,

must be determined during runtime. How this is realized depends on the used pro-

gramming language or software platform (e.g. using a special available flag, using a

special method, using pointers which might be null, ...).

[PRS_SOMEIP_00201] dA Data ID shall be unique within the direct members of a

struct or arguments of a method.c(RS_SOMEIP_00050)

Note:

Please note that a Data ID does not need to be unique across different structs or

methods.

Note:

Please note that neither the AUTOSAR Methodology nor AUTOSAR CP RTE, nor

AUTOSAR AP ara::com support the definition or usage of optional method arguments

at the time being.

[PRS_SOMEIP_00230] dA Data ID shall be defined either for all members of the same

hierarchical level of a struct or for none of them.c(RS_SOMEIP_00050)

[PRS_SOMEIP_00231] dA Data ID shall be defined either for all arguments of a

method or for none of them.c(RS_SOMEIP_00050)

In addition to the Data ID, a wire type encodes the datatype of the following member.

Data ID and wire type are encoded in a so-called tag.

[PRS_SOMEIP_00202] dThe length of a tag shall be two bytes.c(RS_SOMEIP_00050)

[PRS_SOMEIP_00203] dThe tag shall consist of

• reserved (Bit 7 of the first byte)

• wire type (Bit 6-4 of the first byte)

• Data ID (Bit 3-0 of the first byte and bit 7-0 of the second byte)

c(RS_SOMEIP_00050)

Refer to the Figure 4.6 for the layout of the tag. Bit 7 is the highest significant bit of a

byte, bit 0 is the lowest significant bit of a byte.

Wire Type

Data ID (Higher

Sig. Part)

Data ID (Lower Sig. Part) Length Field (8/16/32 bit) Member Data ...

Byte n Byte n + 1 Byte n + 2 ...

7 0 7 0 7/15/31 0

reserved

Figure 4.6: Tag Layout

30 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIP_00204] dThe lower significant part of the Data ID of the member shall

be encoded in bits 7-0 of the second byte of the tag. The higher significant part of the

Data ID of the member shall be encoded in bits 3-0 of the first byte.c(RS_SOMEIP_-

00050)

Example:

The Data ID of the member is 0x04F2. Then bits 3-0 of the first byte are set to 0x4.

The second byte is set to 0xF2.

[PRS_SOMEIP_00205] dThe wire type shall determine the type of the following data

of the member. The value shall be assigned as shown in Table 4.7.c(RS_SOMEIP_-

00050)

Wire Type Following Data

0 8 Bit Data Base data type

1 16 Bit Data Base data type

2 32 Bit Data Base data type

3 64 Bit Data Base data type

4 Complex Data Type: Array, Struct,

String, Union with length field of

static size (configured in data defi-

nition)

5 Complex Data Type: Array, Struct,

String, Union with length field size 1

byte (ignore static definition)

6 Complex Data Type: Array, Struct,

String, Union with length field size 2

byte (ignore static definition)

7 Complex Data Type: Array, Struct,

String, Union with length field size 4

byte (ignore static definition)

Table 4.7: Message Types

Note:

wire type 4 ensures the compatibility with the current approach where the size of length

fields is statically configured. This approach has the drawback that changing the size

of the length field during evolution of interfaces is always incompatible. Thus, wire

types 5, 6 and 7 allow to encode the size of the used length field in the transferred byte

stream. A serializer may use this, if the statically configured size of the length field is

not sufficient to hold the current size of the data struct.

[PRS_SOMEIP_00206] dIf the wire type is set to 5, 6 or 7, the size of the length field

defined in the data definition shall be ignored and the size of the length field shall be

selected according to the wire type.c(RS_SOMEIP_00050)

If a Data ID is configured for a member of a struct/argument of a method, a tag shall

be inserted in the serialized byte stream.

31 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

Note:

regarding the existence of Data IDs, refer to [PRS_SOMEIP_00230] and

[PRS_SOMEIP_00231].

[PRS_SOMEIP_00212] dIf the datatype of the serialized member/argument is a basic

datatype (wire types 0-3) and a Data ID is configured, the tag shall be inserted directly

in front of the member/argument. No length field shall be inserted into the serialized

stream.c(RS_SOMEIP_00028, RS_SOMEIP_00050)

[PRS_SOMEIP_00213] dIf the datatype of the serialized member/argument is not a

basic datatype (wire type 4-7) and a Data ID is configured, the tag shall be inserted in

front of the length field.c(RS_SOMEIP_00028, RS_SOMEIP_00050)

[PRS_SOMEIP_00214] dIf the datatype of the serialized member/argument is not a

basic datatype and a Data ID is configured, a length field shall always be inserted in

front of the member/argument.c(RS_SOMEIP_00028, RS_SOMEIP_00050)

Rationale:

The length field is required to skip unknown members/arguments during deserializa-

tion.

[PRS_SOMEIP_00221] dThe length field shall always contain the length up to the next

tag of the struct.c(RS_SOMEIP_00040, RS_SOMEIP_00050)

[PRS_SOMEIP_00208] dIf the member itself is of type struct, there shall be

exactly one length field. The length field is added according to require-

ments [PRS_SOMEIP_00079] and [PRS_SOMEIP_00370].c(RS_SOMEIP_00040,

RS_SOMEIP_00050)

[PRS_SOMEIP_00225] dIf the member itself is of type dynamic length string, there

shall be exactly one length field. The length field is added according to re-

quirements [PRS_SOMEIP_00089], [PRS_SOMEIP_00090], [PRS_SOMEIP_00093],

[PRS_SOMEIP_00094] and [PRS_SOMEIP_00095].c(RS_SOMEIP_00050)

[PRS_SOMEIP_00224] dIf the member itself is of type fixed length string, there shall

be exactly one length field corresponding to dynamic length str ings.c(RS_SOMEIP_-

00050)

Note:

when serialized without tag, fixed length strings do not have a length field. For the

serialization with tag, a length field is also required for fixed length strings in the same

way as for dynamic length strings.

[PRS_SOMEIP_00227] dIf the member itself is of type dynamic length array, there

shall be exactly one length field. The length field is added according to requirements

[PRS_SOMEIP_00376], [PRS_SOMEIP_00107], [PRS_SOMEIP_00377] with a size

of 8, 16 or 32 bit.c(RS_SOMEIP_00050)

[PRS_SOMEIP_00226] dIf the member itself is of type fixed length array, there shall

be exactly one length field corresponding to dynamic length arrays.c(RS_SOMEIP_-

00050)

32 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIP_00228] dIf the member itself is of type union, there shall be ex-

actly one length field. The length field is added according to requirements

[PRS_SOMEIP_00119], [PRS_SOMEIP_00121] with a size of 8,16 or 32 bit.c(RS_-

SOMEIP_00050)

[PRS_SOMEIP_00229] dIf the member itself is of type union, the length field shall

cover the size of the type field, data and padding bytes.c(RS_SOMEIP_00050)

Note:

For the serialization without tags, the length field of unions does not cover the type

field (see [PRS_SOMEIP_00126]). For the serialization with tags, it is required that the

complete content of the serialized union is covered by the length field.

[PRS_SOMEIP_00210] dA member of a non-extensible (standard) struct which is of

type extensible str uct, shall be serialized according to the requirements for extensible

structs.c(RS_SOMEIP_00028, RS_SOMEIP_00050)

[PRS_SOMEIP_00211] dA member of an extensible struct which is of type non-

extensible (standard) struct, shall be ser ialized according to the requirements for stan-

dard structs.c(RS_SOMEIP_00028, RS_SOMEIP_00050)

[PRS_SOMEIP_00222] dThe alignment of variable length data according to

[PRS_SOMEIP_00611] shall always be 8 bit.c(RS_SOMEIP_00029, RS_SOMEIP_-

00050)

Rationale:

When alignment greater 8 bits is used, the serializer may add padding bytes after

variable length data. The padding bytes are not covered by the length field. If the

receiver does not know the Data ID of the member, it also does not know that it is

variable length data and that there might be padding bytes.

[PRS_SOMEIP_00241] dIf TLV is used the size of the length field for arrays, structs,

unions and strings shall be greater than 0.c(RS_SOMEIP_00050)

Rationale:

The TLV serialization requires the usage of length fields. When wire type 4 is used, the

length field size must be statically configured. When wire types 5-7 (dynamic length

field size) are used, the static configuration of the length field size must also be present

since not all length fields are preceded by a tag, e.g. structs contained in an array or

the top-level struct contained in a SOME/IP event. Not using length fields here would

result in ambiguities.

[PRS_SOMEIP_00242] dThe configured size of the length field for arrays, structs,

unions and strings shall be identical.c(RS_SOMEIP_00050)

Rationale:

In case of an unknown member or argument, the deserializer cannot determine the

actual datatype of the member/argument when wire type 4 is used.

[PRS_SOMEIP_00243] dThe size of the length field shall be configured for the top-

level struct or method request/response. All arrays, unions, structs and strings used

33 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

within a struct or all arguments within a method shall inherit the size of the length field

from the top-level definition.c(RS_SOMEIP_00050)

Rationale:

In case of an unknown member or argument, the deserializer needs to know the size of

the length field when wire type 4 is used. The easiest way is that the size of the length

field is then only defined at the top-level element.

[PRS_SOMEIP_00244] dOverriding the size of the length field at a subordinate array,

union, struct or string or at an individual method argument shall not be allowed.c(RS_-

SOMEIP_00050)

[PRS_SOMEIP_00216] dThe serializer shall not include optional members/arguments

in the serialized byte stream if they are mar ked as not available.c(RS_SOMEIP_00028,

RS_SOMEIP_00050)

[PRS_SOMEIP_00223] dThe deserializer shall ignore optional members/arguments

which are not available in the serialized byte stream.c(RS_SOMEIP_00050)

[PRS_SOMEIP_00217] dIf the deserializer reads an unknown Data ID (i.e. not con-

tained in its data definition), it shall skip the unknown member/argument by using the

information of the wire type and length field.c(RS_SOMEIP_00050)

[PRS_SOMEIP_00218] dIf the deserializer cannot find a required (i.e. non-optional)

member/argument defined in its data definition in the serialized byte stream, the de-

serialization shall be aborted and the message shall be treated as malfor med.c(RS_-

SOMEIP_00050)

[PRS_SOMEIP_00220] dIf the serialization with tags will be introduced for an existing

service interface where tags have not been used, the major interface version shall be

incremented and used to indicate this.c(RS_SOMEIP_00028, RS_SOMEIP_00050)

Note:

The receiver only handles received messages that match all configured val-

ues of Message ID, Protocol Version, Interface Version and Message-Type (see

[PRS_SOMEIP_00195]).

34 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

Example for serializing structures with tags

struct myStruct

unit8 a /* Data ID = 0 */

uint8 b /* Data ID = 1 */

struct c /* Data ID = 2 */

uint8 c1

uint8 c2

struct c3

uint8 c31

struct c32

uint8 c321

uint8[] c322

uint8 c323

uint8 c33

uint8[]c4

uint8 c5

uint8 d /* Data ID = 3 */

struct e /* Data ID = 4 */

uint8 e1

uint8 e2

uint8 f /* Data ID = 5 */

uint8 g /* Data ID = 6 */

myStruct_length

a_tag = 0x0000

b_tag = 0x0001

c_tag = 0x4002

c_length

c3_length

c31

c32_length

c321

c322_length

c322

…

c323

c33

c4_length

…

d_tag = 0x0003

e_tag = 0x4004

e_length

f_tag = 0x0005

g_tag = 0x0006

Figure 4.7: Example 01 for serializing structures with tags

35 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

struct myStruct

unit8 a

uint8 b

struct c

uint8 c1

uint8 c2

struct c3

uint8 c31 /* Data ID = 0 */

struct c32 /* Data ID = 2 */

uint8 c321

uint8[] c322

uint8 c323

uint8 c33 /* Data ID = 1 */

uint8[]c4

uint8 c5

uint8 d

struct e

uint8 e1

uint8 e2

uint8 f

uint8 g

myStruct_length

c_length

c3_length

c31_tag = 0x0000

c31

c32_tag = 0x4002

c32_length

c321

c322_length

c322

…

c323

c33_tag = 0x0001

c33

c4_length

…

e_length

Figure 4.8: Example 02 for serializing structures with tags

struct myStruct

unit8 a

uint8 b

struct c

uint8 c1

uint8 c2

struct c3

uint8 c31

struct c32

uint8 c321 /* Data ID = 2 */

uint8[] c322 /* Data ID = 1 */

uint8 c323 /* Data ID = 0 */

uint8 c33

uint8[]c4

uint8 c5

uint8 d

struct e

uint8 e1

uint8 e2

uint8 f

uint8 g

myStruct_length

c_length

c3_length

c31

c32_length

c321_tag = 0x0002

c321

c322_tag = 0x4001

c322_length

c322

…

c323_tag = 0x0000

c323

c33

c4_length

…

e_length

Figure 4.9: Example 03 for serializing structures with tags

Note:

In the examples Figure 4.7, Figure 4.8 and Figure 4.9 the top-level struct has a length

field because it is assumed that the size of the length field is statically configured.

36 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

According to [PRS_SOMEIP_00243], the size of length field is configured for the top-

level struct and is passed on to the sub elements. Thus, the top-level struct itself has a

length field due to [PRS_SOMEIP_00925] and [PRS_SOMEIP_00926].

When the size of the length field is not statically configured (i.e. using wire types 5-7),

the top-level struct would not have a length field.

Example for serialization of arguments with tags

SOME/IP Header (Request)

a_tag = 0x0000

b_tag = 0x0002

c_tag = 0x4003

c_length

...

SOME/IP Header (Response)

d_tag = 0x2000

e_tag = 0x0001

uint8 myFunction ( IN uint8 a, IN uint8 b, IN myStruct c, OUT uint32 d, OUT uint8 e)

/* Data ID = 0 */ /* Data ID = 2 */ /* Data ID = 3 */ /*Dat a ID = 0 */ /*Data ID = 1 */

Figure 4.10: Example for serialization of arguments with tags

Note:

In the example Figure 4.10 there is no additional length field between the end of the

SOME/IP header and the first tag. This would be redundant to the message length

field in the SOME/IP header.

4.1.4.4 Strings

Following requirements are common for both fixed length and dynamic length strings.

[PRS_SOMEIP_00372] dDifferent Unicode encoding shall be supported including

UTF-8, UTF-16BE and UTF-16LE.c(RS_SOMEIP_00038)

[PRS_SOMEIP_00948] dUTF-8 strings shall be zero terminated with a "\0" character.

This means they shall end with a 0x00 Byte.c(RS_SOMEIP_00038)

[PRS_SOMEIP_00084] dUTF-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)

37 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIP_00085] dUTF-16LE and UTF-16BE strings shall have an even length.c

(RS_SOMEIP_00038)

[PRS_SOMEIP_00086] dUTF-16LE and UTF-16BE strings having an odd length the

last byte shall be ignored.c(RS_SOMEIP_00038)

[PRS_SOMEIP_00087] dAll strings shall always start with a Byte Order Mark (BOM)

in the first three (UTF-8) or two (UTF-16) bytes of the to be serialized array containing

the string. 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.4.1 Strings (fixed length)

[PRS_SOMEIP_00373] dStrings shall be terminated with a "\0"-character despite hav-

ing a fixed length.c(RS_SOMEIP_00038)

[PRS_SOMEIP_00374] dThe length of the string (this includes the "\0") in Bytes has to

be specified in the data type definition.c(RS_SOMEIP_00038)

[PRS_SOMEIP_00911] dIf 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] dIf the length of a str ing 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] dIf the length of a str ing 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)

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.2). Please note that this requires the full string

handling (e.g. endianness conversion) to be done in the applications.

4.1.4.4.2 Strings (dynamic length)

[PRS_SOMEIP_00089] dStrings with dynamic length shall start with a length field. The

length is measured in Bytes.c(RS_SOMEIP_00039)

[PRS_SOMEIP_00090] dThe length field is placed before the BOM, and the BOM is

included in the length.c(RS_SOMEIP_00039)

[PRS_SOMEIP_00091] dString are terminated with a "\0".c(RS_SOMEIP_00039)

38 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

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] dDynamic length strings shall have a length field of 8, 16 or 32

Bits. This shall be determined by configuration.c(RS_SOMEIP_00039)

[PRS_SOMEIP_00094] dIf not configured the length of the length field that is added

in front of the string is 32 Bits (default length of length field).c(RS_SOMEIP_00039,

RS_SOMEIP_00040)

[PRS_SOMEIP_00095] dThe 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] dIf the length of a string with variable length is greater than

expected (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_-

00039)

4.1.4.5 Arrays

4.1.4.5.1 Arrays (fixed length)

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_00944] dArrays with fixed length may start with an optional length

field.c(RS_SOMEIP_00036)

[PRS_SOMEIP_00917] dIf the length of a 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] dIf 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)

Note: Overruns of fixed-size arrays can only be detected with a length field.

39 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

One-dimensional

[PRS_SOMEIP_00099] dThe one-dimensional arrays with fixed length "n" shall carry

exactly "n" elements of the same type. An optional length field may preceed the first

element (see [PRS_SOMEIP_00944].c(RS_SOMEIP_00035, RS_SOMEIP_00036)

Note: If a length field is defined for a specific fixed-length array, then this array is rep-

resented on the bus as a composite of the length field and the collection of n elements

of the same data type.

The layout of [PRS_SOMEIP_00099] is shown in Figure 4.11.

LengthField

(optional)

Element_1 Element_2 Element_n

…

LengthField + n*e

element size e

Element_3

Static Array [n]

n*e

Figure 4.11: One-dimensional array (fixed length)

Multidimensional

[PRS_SOMEIP_00101] dThe serialization of multidimensional arrays follows the in-

memory layout of multidimensional arrays in the C/C++ programming language (row-

major order).c(RS_SOMEIP_00028, RS_SOMEIP_00035, RS_SOMEIP_00036)

Note: If a length field is defined for a specific multidimensional fixed-length array, then

this array is represented on the bus as a composite of a length field and n collections

consisting each of a length field and m elements of the same data type.

The layout of [PRS_SOMEIP_00101] is shown in Figure 4.12.

40 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

LengthField

(optional)

Element_1

…

LengthField + n*(LengthField + m*e)

Static Array [n][m]

n*(LengthField + m*e)

Element_n

LengthField

(optional)

1,1

1,m

m*e

Element_2

…

LengthField

(optional)

2,1

2,m

…

Figure 4.12: Multidimensional array (fixed length)

4.1.4.5.2 Dynamic Length Arrays

[PRS_SOMEIP_00375] dThe layout of arrays with dynamic length shall be based on

the layout of fixed length arrays.c(RS_SOMEIP_00037)

[PRS_SOMEIP_00376] dAn 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] dThe 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] dThe 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.13 and Figure 4.14.

41 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

Figure 4.13: 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.14 shows the structure of a Multidimensional Array of dynamic length.

Element_a[1][j…k_1]

L_1 [Bytes]

Length n

32 Bit

1,1

1,2

1,k_1

…

L_1

Element_a[2][j…k_2]

1,1

1,2

1,k_2

…

L_2

32 Bit

…

L_2 [Bytes]

32 Bit

n [Bytes]

Figure 4.14: Multidimensional array (dynamic length)

[PRS_SOMEIP_00114] dIn multidimensional arrays every sub array of different dimen-

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

42 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

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.14. 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] dIf the length of a variable 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_00037)

[PRS_SOMEIP_00945] dIf not configured the length of the length field that is added

in front of the dynamic length array is 32 Bits (default length of length field).c(RS_-

SOMEIP_00037, RS_SOMEIP_00040)

4.1.4.6 Enumeration

[PRS_SOMEIP_00705] dEnumerations are not considered in SOME/IP. Enumera-

tions shall be transmitted as unsigned integer datatypes.c(RS_SOMEIP_00030, RS_-

SOMEIP_00033)

4.1.4.7 Bitfield

[PRS_SOMEIP_00300] dBitfields shall be transported as unsigned datatypes

uint8/uint16/uint32/uint64.c(RS_SOMEIP_00033, RS_SOMEIP_00030)

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.

43 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIP_00118] dA union shall be used to transport data with alternative data

types over the network.c(RS_SOMEIP_00034)

[PRS_SOMEIP_00119] dA 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] dThe 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] dThe length of the length field shall be defined by configuration

and shall be 32, 16, 8, or 0 bitsc(RS_SOMEIP_00034)

[PRS_SOMEIP_00122] dA 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] dIf 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] dThe type field shall specify the data type of the data.c(RS_-

SOMEIP_00034)

[PRS_SOMEIP_00127] dThe 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] dPossible values of the type field shall be defined by the con-

figuration for each union separately.c(RS_SOMEIP_00034)

[PRS_SOMEIP_00907] dThe value 0 of the type field shall be reserved for the NULL

type.c(RS_SOMEIP_00024, RS_SOMEIP_00034)

Note:

This denotes an empty union.

[PRS_SOMEIP_00908] dWhether NULL is allowed for a union or not shall be defined

by configuration.c(RS_SOMEIP_00034)

[PRS_SOMEIP_00130] dThe payload is serialized depending on the type in the type

field.c(RS_SOMEIP_00028, 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).

44 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

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] dIf 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] dIf 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] dIf 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.c(RS_SOMEIP_00015)

For details of see Chapter 4.2.1.3

[PRS_SOMEIP_00535] dAll 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)

45 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIP_00142] dThe receiving SOME/IP implementation shall be capable 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).

[PRS_SOMEIP_00140] dThe header format allows transporting more than one

SOME/IP message in a single 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 packet length field, SOME/IP shall determine if there are additional SOME/IP mes-

sages in the packet. This shall apply for UDP and TCP transport.c(RS_SOMEIP_-

00010)

[PRS_SOMEIP_00141] dEach SOME/IP payload shall have its own SOME/IP header.c

(RS_SOMEIP_00010, RS_SOMEIP_00027)

[PRS_SOMEIP_00940] dOne Service-Instance can use the following setup for its com-

munication of all the methods, events, and notifications:

• up to one TCP connection

• up to one UDP unicast connection

• up to one UDP multicast connection

c(RS_SOMEIP_00010, RS_SOMEIP_00027)

4.2.1.1 UDP Binding

[PRS_SOMEIP_00139] dThe UDP binding of SOME/IP shall be achieved by transport-

ing SOME/IP messages in UDP packets.c(RS_SOMEIP_00010)

[PRS_SOMEIP_00137] dSOME/IP protocol shall not restrict the usage of UDP frag-

mentation.c(RS_SOMEIP_00010)

[PRS_SOMEIP_00943] dThe client and server shall use a single UDP unicast connec-

tion for all methods, events, and notifications of a Service-Instance which are config-

ured to be communicated using UDP unicast.c(RS_SOMEIP_00010)

[PRS_SOMEIP_00942] dThe client and server may use a single UDP multicast ad-

dress per each Service-Instance which are configured to be communicated using UDP

multicast.c(RS_SOMEIP_00010)

46 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

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] dWhen 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] dThe client and server shall use a single TCP connection for

all methods, events, and notifications of a Service-Instance which are configured to be

communicated using TCP.c(RS_SOMEIP_00010)

[PRS_SOMEIP_00708] dThe 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] dThe TCP connection shall be closed by the client, when the

TCP connection is not required anymore.c(RS_SOMEIP_00010)

[PRS_SOMEIP_00710] dThe 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] dThe 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.

Allowing resync to TCP stream using Magic Cookies

[PRS_SOMEIP_00154] dIn order to allow testing tools to identify the boundaries of

SOME/IP Message transported via TCP, the SOME/IP Magic Cookie Message may be

inserted into the SOME/IP messages over TCP message stream at regular distances.c

(RS_SOMEIP_00010)

[PRS_SOMEIP_00160] dThe layout of the Magic Cookie Messages shall consist of the

followign fields:

• for communincation from Client to Server:

47 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

– Message ID (Service ID/Method ID): 0xFFFF 0000

– Length: 0x0000 0008

– Request ID (Client ID/Session ID): 0xDEAD BEEF

– Protocol Version: 0x01

– Interface Version: 0x01

– Message Type: 0x01

– Return Code: 0x00

• for communincation from Server to Client:

– Message ID (Service ID/Method ID): 0xFFFF 8000

– Length: 0x0000 0008

– Request ID (Client ID/Session ID): 0xDEAD BEEF

– Protocol Version: 0x01

– Interface Version: 0x01

– Message Type: 0x02

– Return Code: 0x00

c(RS_SOMEIP_00010)

The layout of the Magic Cookie Messages is shown in Figure 4.15.

48 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

Protocol Version [8 bit]

=0x01

Interface Version [8 bit]

=0x01

Message Type [8 bit]

=0x01

Return Code [8 bit]

=0x00

Request ID (Client ID / Session ID) [32 bit]

= 0xDEAD BEEF

Length [32 bit]

= 0x0000 0008

Message ID (Service ID / Method ID ) [32 bit]

(= 0xFFFF 0000 )

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

Covered

by Length

Protocol Version [8 bit]

=0x01

Interface Version [8 bit]

=0x01

Message Type [8 bit]

=0x02

Return Code [8 bit]

=0x00

Request ID (Client ID / Session ID) [32 bit]

= 0xDEAD BEEF

Length [32 bit]

= 0x0000 0008

Message ID (Service ID / Method ID ) [32 bit]

(= 0xFFFF 8000 )

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

Covered

by Length

Client  Server:

Server  Client:

Figure 4.15: SOME/IP Magic Cookie Message for SOME/IP

4.2.1.3 Multiple Service-Instances

[PRS_SOMEIP_00162] dService-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_00015)

[PRS_SOMEIP_00163] dWhile several Service-Instances of 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 use different ports per

Service-Instance.c(RS_SOMEIP_00015)

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.

49 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

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 transpor ted 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 transpor ted 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] dSOME/IP messages using SOME/IP-TP shall activate Ses-

sion Handling (Session ID must be unique for the original message).c(RS_SOMEIP_-

00010, RS_SOMEIP_00012)

[PRS_SOMEIP_00721] dAll 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_00012)

[PRS_SOMEIP_00722] dSOME/IP-TP segments shall have the TP-Flag of the Mes-

sage Type set to 1.c(RS_SOMEIP_00010, RS_SOMEIP_00011)

[PRS_SOMEIP_00723] dSOME/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_00027)

SOME-IP-TP-Header is as shown in Figure 4.16.

50 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

Figure 4.16: SOME/IP TP header

[PRS_SOMEIP_00931] dSOME/IP-TP Header shall be encoded in network byte order

(big endian).c(RS_SOMEIP_00027)

[PRS_SOMEIP_00724] dThe Offset field shall transport the upper 28 bits of a

uint32. The lower 4 bits shall be always interpreted as 0.c(RS_SOMEIP_00010, RS_-

SOMEIP_00027)

Note:

This means that the offset field can only transport offset values that are multiples of 16

bytes.

[PRS_SOMEIP_00725] dThe 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_00027)

[PRS_SOMEIP_00726] dThe 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_-

00027)

[PRS_SOMEIP_00727] dThe 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_00027)

[PRS_SOMEIP_00728] dThe 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

(RS_SOMEIP_00010, RS_SOMEIP_00027) Note:

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] dThe 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_00051)

51 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIP_00730] Maximum segement length dUDP-based SOME/IP mes-

sages are limited to 1400 bytes payload. Due to this, the maximum length of a segment

that is correctly aligned is 1392 bytes.c(RS_SOMEIP_00010, RS_SOMEIP_00029,

RS_SOMEIP_00051)

[PRS_SOMEIP_00731] dSOME/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 Ver-

sion, Interface Version, and Return Code as the original message.c(RS_SOMEIP_-

00010, RS_SOMEIP_00051) Note:

As described above the Length, Message Type, and Payload are adapted by SOME/IP-

TP.

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.17: 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 Retur n 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:

52 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

Figure 4.18: 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.19: 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’.

53 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

Figure 4.20: Example: Header of the last SOME/IP segment

Sender specific behavior

[PRS_SOMEIP_00732] dThe sender shall segment only messages that were config-

ured to be segmented.c(RS_SOMEIP_00010, RS_SOMEIP_00051)

[PRS_SOMEIP_00733] dThe sender shall send segments in ascending order.c(RS_-

SOMEIP_00010, RS_SOMEIP_00051)

[PRS_SOMEIP_00734] dThe 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_00051)

[PRS_SOMEIP_00735] dThe sender shall try to maximize the size of segments within

limitations imposed by this specification.c(RS_SOMEIP_00010, RS_SOMEIP_00051)

[PRS_SOMEIP_00736] dThe sender shall not send overlapping or duplicated seg-

ments.c(RS_SOMEIP_00010, RS_SOMEIP_00051)

Receiver specific behavior

[PRS_SOMEIP_00738] dThe 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_00051)

[PRS_SOMEIP_00740] dIt shall be supported to reassemble multiple messages with

the same Message ID but sent from different clients (difference in Sender IP, Sender

54 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

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

[PRS_SOMEIP_00741] dThe Session ID shall be used to detect the next original mes-

sage to be reassembled.c(RS_SOMEIP_00010, RS_SOMEIP_00051)

[PRS_SOMEIP_00742] dThe receiver shall start a new reassembly (and may 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_00051)

[PRS_SOMEIP_00743] dThe receiver should only reassemble up to its configured

buffer size and skip the rest of the message.c(RS_SOMEIP_00010, RS_SOMEIP_-

00051)

[PRS_SOMEIP_00744] dOnly correctly reassembled message of up to the configured

size shall be passed to an application.c(RS_SOMEIP_00010, RS_SOMEIP_00051)

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] dThe Return Code of the last segment used for reassembly

shall be used for the reassembled message.c(RS_SOMEIP_00010, RS_SOMEIP_-

00051)

[PRS_SOMEIP_00746] dDuring 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_00051)

[PRS_SOMEIP_00747] dThe receiver shall support reassembly of segments that are

received in ascending and descending order.c(RS_SOMEIP_00010, RS_SOMEIP_-

00051)

[PRS_SOMEIP_00749] dWhen a missing segment is detected during assembly of a

SOME/IP message, the current assembly process shall be canceled.c(RS_SOMEIP_-

00010, RS_SOMEIP_00051) Note:

This means that reordering is not supported.

[PRS_SOMEIP_00750] dInterleaving of different segmented messages using the

same buffer (e.g. only the Session-ID and payload are different) is not supported.c

(RS_SOMEIP_00010, RS_SOMEIP_00051)

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] dReordering 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_00051)

55 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIP_00752] dThe receiver shall correctly reassemble overlapping and du-

plicated segments by overwriting based on the last received segment.c(RS_SOMEIP_-

00010, RS_SOMEIP_00051)

[PRS_SOMEIP_00753] dThe 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_00051)

[PRS_SOMEIP_00754] dThe 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_00051) Note:

This means that buffer overflows or other malfunction shall be prevented by the receiv-

ing 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] dFor 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] dTo construct the payload of a request message, all input or

inout arguments of the method shall be serialized according to the order of the argu-

ments within the signature of the method.c(RS_SOMEIP_00028, RS_SOMEIP_00007)

[PRS_SOMEIP_00922] dThe server builds the header of the response based on the

header of the client’s request and does in addition:

• Construct the payload

• take over the Message ID from the corresponding request

56 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

• 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 a return code according to [PRS_SOMEIP_00191].

c(RS_SOMEIP_00007)

For the valid return codes, see Table 4.11.

[PRS_SOMEIP_00923] dTo 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_00028, RS_SOMEIP_-

00007)

[PRS_SOMEIP_00927] dA 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] dA 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] dFor the SOME/IP request-no-return 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_NO_RETURN (i.e. 0x01)

• Set the Return Code to 0x00

c(RS_SOMEIP_00006)

[PRS_SOMEIP_00171] dFire & Forget messages shall not return an error. Error han-

dling and return codes shall be implemented by the application when needed.c(RS_-

SOMEIP_00006)

57 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

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] dFor the SOME/IP notification message the server has to do

the following for payload and header:

• Construct the payload

• Set the Message ID based on the event the server wants to send

• Set the Length field to 8 bytes (for the part of the SOME/IP header after the length

field) + length of the serialized payload

• Set the Client ID to 0x00. Set the Session ID according to

[PRS_SOMEIP_00932], [PRS_SOMEIP_00933], and [PRS_SOMEIP_00521].

In case of active Session Handling the Session ID shall be incremented upon

each transmission.

• Set the Protocol Version according [PRS_SOMEIP_00052]

• Set the Interface Version according to the interface definition

• Set the Message Type to NOTIFICATION (i.e. 0x02)

• Set the Return Code to 0x00

c(RS_SOMEIP_00004)

[PRS_SOMEIP_00926] dThe payload of the notification message shall consist of the

serialized data of the event.c(RS_SOMEIP_00004)

[PRS_SOMEIP_00930] dWhen more than one subscribed client on the same ECU

exists, the system shall handle the replication of notifications in order to save transmis-

sions on the communication medium.c(RS_SOMEIP_00042)

This is especially important, when notifications are transported using multicast mes-

sages.

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)

58 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

• 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] dA field shall be a combination of getter, setter and notification

event.c(RS_SOMEIP_00009)

[PRS_SOMEIP_00180] dA 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] dThe 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] dThe 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] dThe 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_-

00002, RS_SOMEIP_00009)

[PRS_SOMEIP_00183] dThe notifier shall send an event message that transports the

value of a field on change and follows the rules for events.c(RS_SOMEIP_00005,

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

59 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

Which one of both is used, depends on the configuration.

[PRS_SOMEIP_00901] dReturn 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] dExplicit Error Messages shall be used to transport application

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] dIf more detailed error information 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.2)

[PRS_SOMEIP_00904] dOnly 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] dAll other messages than 0x80 and 0x81 shall set this field to

0x00.c(RS_SOMEIP_00008)

For message type see Chapter 4.1.2.7.

4.2.6.1 Return Code

[PRS_SOMEIP_00187] dThe return code shall be UINT8.c(RS_SOMEIP_00008)

[PRS_SOMEIP_00191] dCurrently defined Return Codes are shown in Table 4.11c

(RS_SOMEIP_00008, RS_SOMEIP_00024)

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.

60 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

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

Version of SOME/IP protocol not supported

0x08 E_WRONG_INTERFACE_

VERSION

Interface version mismatch

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 E_E2E_REPEATED Repeated E2E calculation error

0x0c E_E2E_WRONG_SEQUENCE Wrong E2E sequence error

0x0d E_E2E Not further specified E2E error

0x0e E_E2E_NOT_AVAILABLE E2E not available

0x0f E_E2E_NO_NEW_DATA No new data for E2E calculation present.

0x10 -

0x1f

RESERVED Reserved for generic SOME/IP errors. These errors

will be specified in future versions of this document.

0x20 -

0x5E

RESERVED Reserved for specific errors of services and meth-

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

61 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIP_00188] dThe receiver of a SOME/IP message shall not retur n an error

message for events/notifications.c(RS_SOMEIP_00008)

[PRS_SOMEIP_00189] dThe receiver of a SOME/IP message shall not retur n an error

message for fire&forget methods.c(RS_SOMEIP_00008)

[PRS_SOMEIP_00537] dThe receiver of a SOME/IP message shall not retur n an error

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] dFor 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] dError 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, RS_SOMEIP_00014)

[PRS_SOMEIP_00910] dFor 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, RS_-

SOMEIP_00014)

[PRS_SOMEIP_00195] dSOME/IP messages shall be checked by error processing.

This does not include the application based error handling but just covers the error

handling in messaging and RPC.c(RS_SOMEIP_00008, RS_SOMEIP_00014)

An overview of the error processing is shown in Figure 4.21.

62 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

Figure 4.21: Message Validation and Error Handling in SOME/IP

[PRS_SOMEIP_00614] dWhen 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,

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

63 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

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

processing

reqReceived

waitingForResponse

/ sendReq rspReceived

rspTimeout

/ sendRsp

Error: NoResponse

Client

Server

Figure 4.22: State Machines for Reliability "Maybe"

For "exactly once" reliability the TCP binding may be used, since TCP was defined to

allow for reliable communication.

4.3 Compatibility Rules for Interface Version

The Interface Version identifies the Payload format. The Payload format is affected by

• the Service Interface specification

• the serialization configuration (e.g. usage of variable size arrays, size of length

fields, padding, TLV, SOME/IP-TP).

64 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIP_00937] dThe Interface Version shall be increased for any of the follow-

ing reasons:

• incompatible changes in the Payload format

• incompatible changes in the service behaviour

• required by application design

c(RS_SOMEIP_00003)

Note: The Interface Version shall not be increased for compatible changes in the Pay-

load format.

[PRS_SOMEIP_00938] dThe rules in Table 4.12 shall define the compatibility of

changes of the payload format. For complex data types the rules shall be applied

recursively. X denotes a compatible change, an empty cell denotes an incompatible

change.c(RS_SOMEIP_00003)

Note:

This table is based on the specification of the SOME/IP protocol. As a rule of thumb,

interfaces are compatible if the receiver of data finds all expected information on the

expected locations.

Classes of Protocol / Serialization Capa-

bilities

Serialization without length fields

Serialization with length fields

Serialization with TLV

Serialization with TLV and optional members

Change of Interface

Provide

Require

Provide

Require

Provide

Require

Provide

Require

Add a struct member not to the end of the struct

X X X

Add a struct member to the end of the toplevel struct

X X X X X

Add a struct member to the end of a sub-struct

X X X X

Remove struct member not from the end of the struct

X X X

Remove struct member from the end of the toplevel struct

X X X X X

Remove struct member from the end of a sub-struct

X X X X

Reorder struct members

X X X X

Change the non-highest union member (redefine or remove)

65 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

Classes of Protocol / Serialization Capa-

bilities

Serialization without length fields

Serialization with length fields

Serialization with TLV

Serialization with TLV and optional members

Change of Interface

Provide

Require

Provide

Require

Provide

Require

Provide

Require

Add a new union member with previously unused type selector

X X X X

Remove union member with highest type selector

X X X X

Change of data type:

• to a larger one (e.g. uint8 to uint16)

• to a smaller one (e.g. uint16 to uint8

• to a semantically different one (e.g. integer to struct, integer to float,

string to string with different character size)

• byte order

• number of dimensions of arrays

• size of length field of array, struct or union type selector

Add new enumeration values

X X X X

Change existing enumeration values

Remove enumeration values

X X X X

Change length of fixed size string or array

N/A N/A N/A N/A N/A N/A

Decrease maximum length of variable size string

N/A N/A

X X X

Increase maximum length of variable size string

N/A N/A

X X X

Change maximum length of variable size array

N/A N/A

X X X X X X

Add argument not to the end of the argument list of a method request

Remove argument not from the end of the argument list of a method reponse

X X X

Add argument to the end of the argument list of a method request

Remove argument from the end of the argument list of a method reponse

X X X X X

Remove argument not from the end of the argument list of a method request

Add argument not from the end of the argument list of a method response

X X X

Remove argument from the end of the argument list of a method request

Add argument from the end of the argument list of a method response

X X X X X

Reorder arguments of methods

X X X X

Change optionality of argument

N/A N/A N/A N/A N/A N/A

Change the return type of a method (e.g void to uint8)

Add return codes of a method

X X X X

Remove return codes of a method

X X X X

66 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

Classes of Protocol / Serialization Capa-

bilities

Serialization without length fields

Serialization with length fields

Serialization with TLV

Serialization with TLV and optional members

Change of Interface

Provide

Require

Provide

Require

Provide

Require

Provide

Require

Change of the name of a service interface, method or event

X X X X X X X X

Add event ot eventgroup

X X X X

Remove event from eventgroup

X X X X

Add setter or getter to a field

Remove notifier from a field

X X X X

Remove setter or getter from a field

Add notifier to a field

X X X X

Extend service interface by new method, event or field

X X X X

Remove method, event or field from a service interface

X X X X

Change Method ID

Change data ID of argument

Reuse data ID of previously removed argument

N/A N/A N/A N/A

Table 4.12: Payload Compatibility Rules

67 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

5 Configuration Parameters

Configuration Parameters are not handled and described in this document.

68 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

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

69 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

6.3 Insert Padding for structs

If padding is necessary, 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.

6.4 Security Considerations for SOME/IP

[PRS_SOMEIP_00946] Restricting Server Connection from Clients dA server may

enforce communication policies to protect the server from malicious or unauthorized

clients. I.e. the server may reject subscriptions to eventgroups, or method calls from

unauthorized clients.c()

Note: These policies are beyond the scope of this specification. Such policies can be

based on the IP address of the client or any other means to identify the client.

[PRS_SOMEIP_00947] Restricting Client Connection to Server dA client may en-

force communication policies to protect the client from malicious servers. I.e. the client

may deny communication to unauthorized servers.c()

Note: These policies are beyond the scope of this specification. Such policies can be

based on the IP address of the server or any other means to identify the client.

70 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol

SOME/IP Protocol Specification

AUTOSAR FO R22-11

References

[1] Glossary

AUTOSAR_TR_Glossary

71 of 71 Document ID 696: AUTOSAR_PRS_SOMEIPProtocol