AUTOSAR PRS SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification
AUTOSAR FO Release 1.3.0
SOME/IP Service Discovery

Document Title Protocol Specification
Document Owner AUTOSAR
Document Responsibility AUTOSAR
Document Identification No 802
Document Status Final

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

Date Release Changed by Description
AUTOSAR
2017-12-08 1.3.0 Release • minor changes
Management
AUTOSAR
2017-10-27 1.2.0 Release • Editorial changes
Management
• Configuration Parameters SD_PORT
AUTOSAR and SD_MULTICAST_IP are added
2017-03-31 1.1.0 Release and defined
Management • Rules relating to Options are
reordered
AUTOSAR
2016-11-30 1.0.0 Release Initial Release
Management
1 of 74 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

— AUTOSAR CONFIDENTIAL —
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.

Table of Contents
1 Introduction and overview 5
1.1 Protocol purpose and objectives . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Applicability of the protocol . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Constraints and assumptions . . . . . . . . . . . . . . . . . . 5
1.3 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Dependencies to other protocol layers . . . . . . . . . . . . . 5
2 Protocol Requirements 7
2.1 Requirements Traceability . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Acronyms and Abbreviations 15
4 Protocol specification 17
4.1 SOME/IP Service Discovery (SOME/IP-SD) . . . . . . . . . . . . . . . 17
4.1.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1.1 Terms and Definitions . . . . . . . . . . . . . . . . . 17
4.1.2 SOME/IP-SD Message Format . . . . . . . . . . . . . . . . . 17
4.1.2.1 General Requirements . . . . . . . . . . . . . . . . . 17
4.1.2.2 SOME/IP-SD Header . . . . . . . . . . . . . . . . . . 20
4.1.2.3 Entry Format . . . . . . . . . . . . . . . . . . . . . . 23
4.1.2.4 Options Format . . . . . . . . . . . . . . . . . . . . . 26
4.1.2.5 Service Entries . . . . . . . . . . . . . . . . . . . . . 36
4.1.2.6 Endpoint Handling for Services and Events . . . . . 39
4.1.3 Service Discovery Messages . . . . . . . . . . . . . . . . . . 42
4.1.3.1 Eventgroup Entry . . . . . . . . . . . . . . . . . . . . 42
4.1.4 Service Discovery Communication Behavior . . . . . . . . . 45
4.1.4.1 Startup Behavior . . . . . . . . . . . . . . . . . . . . 45
4.1.4.2 Server Answer Behavior . . . . . . . . . . . . . . . . 47
4.1.4.3 Shutdown Behavior . . . . . . . . . . . . . . . . . . . 48
4.1.4.4 State Machines . . . . . . . . . . . . . . . . . . . . . 49
4.1.4.5 SOME/IP-SD Mechanisms and Errors . . . . . . . . 51
4.1.4.6 Error Handling . . . . . . . . . . . . . . . . . . . . . 53
4.1.5 Announcing non-SOME/IP protocols with SOME/IP-SD . . . 55
4.1.6 Publish/Subscribe with SOME/IP and SOME/IP-SD . . . . . 57
4.1.7 Reserved and special identifiers for SOME/IP and SOME/IP-
SD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5 Configuration Parameters 68
6 Protocol Usage 69
6.1 Security Considerations for SOME/IP-SD Options . . . . . . . . . . . . 69
6.2 Mandatory Feature Set and Basic Behavior . . . . . . . . . . . . . . . 69
6.3 Migration and Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 72
6.3.1 Supporting multiple versions of the same service. . . . . . . 72

7 References 74

1 Introduction and overview

This protocol specification specifies the format, message sequences and semantics of
the Protocol SOME/IP Service Discovery (SOME/IP-SD).
The main tasks of the Service Discovery Protocol are communicating the availability
functional entities called services in the in-vehicle communication as well as controlling
the send behavior of event messages. This allows sending only event messages to re-
ceivers requiring them (Publish/Subscribe). The solution described here is also known
as SOME/IP-SD (Scalable service-Oriented MiddlewarE over IP - Service Discovery).
1.1 Protocol purpose and objectives

SOME/IP-SD is used to
• Locate service instances.
• Detect if service instances are running.
• Implement the Publish/Subscribe handling.
1.2 Applicability of the protocol

SOME/IP SD can be used for service discovery in automotive vehicle networks.
1.2.1 Constraints and assumptions
Currently SOME/IP-SD supports only IP based communication.
1.3 Dependencies
1.3.1 Dependencies to other protocol layers
SOME/IP-SD depends on SOME/IP. SOME/IP itself supports both TCP and UDP
communications but SOME/IP SD is constraint to use SOME/IP only over UDP (See
[PRS_SOMEIPSD_00220]).

Figure 1.1: SOME/IP-SD Dependencies to other protocol layers

2 Protocol Requirements
2.1 Requirements Traceability
Feature Description Satisfied by

[RS_SOMEIPSD_00001] SOME/IP Service Discovery Protocol [PRS_SOMEIPSD_00151]
shall be used on top of SOME/IP [PRS_SOMEIPSD_00152]
Protocol [PRS_SOMEIPSD_00153]
[PRS_SOMEIPSD_00154]
shall support unicast messages [PRS_SOMEIPSD_00259]
shall support multicast messages [PRS_SOMEIPSD_00239]


shall support SOME/IP and [PRS_SOMEIPSD_00438]
non-SOME/IP services [PRS_SOMEIPSD_00439]
shall support different versions of the
same service
shall define the format of the Service [PRS_SOMEIPSD_00254]
Discovery message [PRS_SOMEIPSD_00255]

shall define ordered feature sets for [PRS_SOMEIPSD_00497]
compliance of implementations [PRS_SOMEIPSD_00498]
shall support to find the location of [PRS_SOMEIPSD_00351]
service instances [PRS_SOMEIPSD_00496]
shall support to transport text-based
names of services


shall provide support to transport [PRS_SOMEIPSD_00305]
optional data [PRS_SOMEIPSD_00306]
shall provide support for load balancing [PRS_SOMEIPSD_00544]
shall support to detect whether service [PRS_SOMEIPSD_00397]
instances are active [PRS_SOMEIPSD_00427]


shall support to offer published services [PRS_SOMEIPSD_00356]
shall support to stop offering services [PRS_SOMEIPSD_00364]
shall support to subscribe to events [PRS_SOMEIPSD_00121]

shall support to deny subscriptions [PRS_SOMEIPSD_00443]
shall support to stop subscriptions to [PRS_SOMEIPSD_00389]
events [PRS_SOMEIPSD_00427]
shall support reboot detection of
service providers


shall standardize error handling [PRS_SOMEIPSD_00125]
shall support TTL [PRS_SOMEIPSD_00502]
[RS_SOMEIPSD_00021] SOME/IP Service Discovery protocol [PRS_SOMEIPSD_00350]
shall provide functionality to discover [PRS_SOMEIPSD_00351]
services
[RS_SOMEIPSD_00022] SOME/IP Service Discovery shall [PRS_SOMEIPSD_00603]
operate in a distributed manner
[RS_SOMEIPSD_00024] SOME/IP Service Discovery shall [PRS_SOMEIPSD_00502]
support configurable timings
[RS_SOMEIPSD_00025] SOME/IP Service Discovery messages [PRS_SOMEIPSD_00133]
shall contain information how to contact [PRS_SOMEIPSD_00134]
the communication partner [PRS_SOMEIPSD_00341]


3 Acronyms and Abbreviations

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

a method, procedure, function, or subroutine that is called/in-
Method
voked.
Parameters input, output, or input/output arguments of a method or an event
a method call from one ECU to another that is transmitted using
Remote Procedure Call (RPC)
messages
Request a message of the client to the server invoking a method
a message of the server to the client transporting results of a
Response
method invocation
Request/Response communica-
a RPC that consists of request and response
tion
Fire&Forget communication a RPC call that consists only of a request message
A uni-directional data transmission that is only invoked on
changes or cyclically and is sent from the producer of data to
the consumers. One event could even be both sent cyclically and
Event
spontaneously on change. This is completely in the responsibility
of the sending application because the receiver has no means at
all to distinguish between those two.
a field does represent a status and thus has an valid value at all
Field
times on which getter, setter and notfier act upon.
an event message the notifier of an field sends. The message of
such a notifier cannot be distinguished from the event message;
Notification Event
therefore, when refering to the message of an event, this shall
also be true for the messages of notifiers of fields.
Getter a Request/Response call that allows read access to a field.
Setter a Request/Response call that allows write access to a field.
sends out event message with a new value on change of the
Notifier
value of the field.
a logical combination of zero or more methods, zero or more
Service events, and zero or more fields (empty service is allowed, e.g.
for announcing non-SOME/IP services in SOME/IP-SD)
a logical grouping of events and notification events of fields inside
Eventgroup
a service in order to allow subscription
the formal specification of the service including its methods,
Service Interface
events, and fields
software implementation of the service interface, which can exist
Service Instance
more than once in the vehicle and more than once on an ECU
The ECU offering a service instance shall be called server in the
Server
context of this service instance.
The ECU using the service instance of a server shall be called
Client
client in the context of this service instance.
Union or Variant a data structure that dynamically assumes different data types.
that one ECU implements an instance of a service and tells other
Offering a service instance
ECUs using SOME/IP-SD that they may use it.
to send a SOME/IP-SD message in order to find a needed ser-
Finding a service instance
vice instance.

Abbreviation / Acronym: Description:

to send a SOME/IP-SD message to the ECU implementing the
required service instance with the meaning that this service in-
Requiring a service instance
stance is needed by the other ECU. This may be also sent if the
service instance is not running; thus, was not offered yet.
to sent a SOME/IP-SD message to the ECU hosting this service
Releasing a service instance instances with the meaning that the service instance is not longer
needed.
The configuration and required data of a service instance the
Server-Service-Instance-Entry local ECU offers, is called Server-Service-Instance-Entry at the
ECU offering this service (Server).
The configuration and required data of a service instance another
Client-Service-Instance-Entry ECU offers, is called Client-Service-Instance-Entry at the ECU
using this service (Client)
to offer an eventgroup of a service instance to other ECUs using
Publishing an eventgroup
a SOME/IP-SD message
to require an eventgroup of a service instance using a SOME/IP-
Subscribing an eventgroup SD message
Table 3.1: Acronyms and Abbreviations

4 Protocol specification
4.1 SOME/IP Service Discovery (SOME/IP-SD)
4.1.1 General
SOME/IP-SD is used to
• Locate service instances.
• Detect if service instances are running.
• Implement the Publish/Subscribe handling.
Inside the vehicular network service instance locations are commonly known; there-
fore, the state of the service instance is of primary concern. The location of the service
(i.e. IP-Address, transport protocol, and port number) are of secondary concern.
4.1.1.1 Terms and Definitions
[PRS_SOMEIPSD_00238] d A separate server service instance shall be used per

interface if a service instance needs to be offered on multiple interfaces. c
(RS_SOMEIPSD_00003)
[PRS_SOMEIPSD_00239] d A separate client service instance shall be used per inter-
face if a service instance needs to be configured to be accessed using multiple different
interfaces. c(RS_SOMEIPSD_00003)
4.1.2 SOME/IP-SD Message Format
4.1.2.1 General Requirements
[PRS_SOMEIPSD_00220] d SOME/IP-SD messages shall be sent over UDP. c

(RS_SOMEIPSD_00010)
[PRS_SOMEIPSD_00251] d

SOME/IP-SD Header Format is shown in Figure 4.1 c(RS_SOMEIPSD_00001)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 bit offset
Message ID (Service ID / Method ID) [32 bit]
(= 0xFFFF 8100 )
Length [32 bit]

SOME/IP
Request ID (Client ID / Session ID) [32 bit]
Protocol Version [8 bit] Interface Version [8 bit] Message Type [8 bit] Return Code [8 bit]
=0x01 =0x01 =0x02 =0x00
Flags [8 bit] Reserved [24 bit]
Covered by Length
Length of Entries Array [32 bit]
Covered by Length
SOME/IP SD
Entries Array
Length of Options Array [32 bit]
Covered by Length
Options Array
Figure 4.1: SOME/IP-SD Header Format
[PRS_SOMEIPSD_00250] d Service Discovery Messages shall start with a SOME/IP

header as depicted Figure 4.1: c(RS_SOMEIPSD_00001)
[PRS_SOMEIPSD_00151] d Service Discovery messages shall use the Service-ID (16
Bits) of 0xFFFF. c(RS_SOMEIPSD_00001)
[PRS_SOMEIPSD_00152] d Service Discovery messages shall use the Method-ID (16
Bits) of 0x8100. c(RS_SOMEIPSD_00001)
[PRS_SOMEIPSD_00153] d Service Discovery messages shall use a uint32 length
field as specified by SOME/IP. That means that the length is measured in bytes and
starts with the first byte after the length field and ends with the last byte of the SOME/IP-
SD message. c(RS_SOMEIPSD_00001)
[PRS_SOMEIPSD_00154] d Service Discovery messages shall have a Client-ID (16
Bits) set to 0x0000, since there exists only a single SOME/IP-SD instance. c
(RS_SOMEIPSD_00001)
[PRS_SOMEIPSD_00155] d If a Client ID Prefix is configured, it shall also apply to
SOME/IP-SD (See [PRS_SOMEIP_00532] in [2]). c(RS_SOMEIPSD_00001)
[PRS_SOMEIPSD_00156] d Service Discovery messages shall have a Session-ID (16
Bits) and handle it based on SOME/IP requirements. c(RS_SOMEIPSD_00001)
[PRS_SOMEIPSD_00157] d The Session-ID (SOME/IP header) shall be incremented
for every SOME/IP-SD message sent. c(RS_SOMEIPSD_00001)

[PRS_SOMEIPSD_00158] d The Session-ID (SOME/IP header) shall start with 1 and

be 1 even after wrapping. c(RS_SOMEIPSD_00001)
[PRS_SOMEIPSD_00159] d The Session-ID (SOME/IP header) shall not be set to 0.
c(RS_SOMEIPSD_00001)
[PRS_SOMEIPSD_00160] d SOME/IP-SD Session ID handling is done per
"communication relation", i.e. broadcast as well as unicast per peer (see
[PRS_SOMEIPSD_00255]). c(RS_SOMEIPSD_00001)
[PRS_SOMEIPSD_00161] d Service Discovery messages shall have a Protocol-
Version (8 Bits) of 0x01. c(RS_SOMEIPSD_00001)
[PRS_SOMEIPSD_00162] d Service Discovery messages shall have a Interface-
Version (8 Bits) of 0x01. c(RS_SOMEIPSD_00001)
[PRS_SOMEIPSD_00163] d Service Discovery messages shall have a Message Type
(8 bits) of 0x02 (Notification). c(RS_SOMEIPSD_00001)
[PRS_SOMEIPSD_00164] d Service Discovery messages shall have a Return Code
(8 bits) of 0x00 (E_OK). c(RS_SOMEIPSD_00001)

An example of SOME/IP-SD is as shown below
Figure 4.2: SOME/IP-SD Example PDU
4.1.2.2 SOME/IP-SD Header
[PRS_SOMEIPSD_00252] d SOME/IP-SD shall be transported using SOME/IP as de-

picted in Figure 4.2. c(RS_SOMEIPSD_00001)
[PRS_SOMEIPSD_00253] d The SOME/IP-SD Header shall start with an 8 Bit field
called Flags. see a representation of Flags in Figure 4.3 c(RS_SOMEIPSD_00006)

Figure 4.3: Flags in SOME/IP-SD
[PRS_SOMEIPSD_00254] d The first flag of the SOME/IP-SD Flags field (highest order
bit) shall be called Reboot Flag. See Figure 4.3 c(RS_SOMEIPSD_00006)
[PRS_SOMEIPSD_00255] d The Reboot Flag of the SOME/IP-SD Header shall be set
to one for all messages after reboot until the Session-ID in the SOME/IP-Header wraps
around and thus starts with 1 again. After this wrap around the Reboot Flag is set to 0.
[PRS_SOMEIPSD_00256] d The information for the reboot flag and the Session
ID shall be kept for multicast and unicast separately. c(RS_SOMEIPSD_00002,
RS_SOMEIPSD_00003)
[PRS_SOMEIPSD_00631] d The information for the reboot flag and the Session ID
shall be kept for every sender-receiver relation (i.e. source address and destination
address) separately. c(RS_SOMEIPSD_00002, RS_SOMEIPSD_00003)
Note:
This means there shall be separate counters for sending and receiving.
Sending
• There shall be a counter for multicast.
• There shall be a separate counter for each peer for unicast.
Receiving
• There shall be a counter for each peer for multicast.

• There shall be a counter for each peer for unicast.

[PRS_SOMEIPSD_00258] d The detection of a reboot shall be done as follows (with
new the values of the current packet from the communication partner and old the last
value received before):
if old.reboot==0 and new.reboot==1 then Reboot detected

if old.reboot==1 and new.reboot==1 and old.session_id>=new.session_id then Reboot
detected
The following is not enough since we do not have reliable communication:

if new.reboot==1 and old.session_id>=new.session_id then Reboot detected
[PRS_SOMEIPSD_00259] d The second flag of the SOME/IP-SD Flags (second high-
est order bit) shall be called Unicast Flag. See Figure 4.3 c(RS_SOMEIPSD_00002)
[PRS_SOMEIPSD_00540] d The Unicast Flag of the SOME/IP-SD Header shall be set
to Unicast (that means 1) for all SD Messages since this means that receiving using
unicast is supported. c(RS_SOMEIPSD_00002)
Note:
The Unicast Flag is left over from historical SOME/IP versions and is only kept for
compatibility reasons. Its use besides this is very limited.
[PRS_SOMEIPSD_00700] d The third flag of the SOME/IP-SD Flags (third highest
order bit) shall be called Explicit Initial Data Control Flag and shall mean that the ECU
supports explicit initial data control. See Figure 4.3 c(RS_SOMEIPSD_00002)
Note:
This means that the ECU understands and honors the Initial Data Requested Flag
inside of Eventgroup Entries.
[PRS_SOMEIPSD_00701] d The Explicit Initial Data Control Flag shall always be set
to 1, meaning the ECU supports this feature. c(RS_SOMEIPSD_00002)
Note:
This flag allows compatibility to older SOME/IP-SD implementations (e.g. AUTOSAR
4.2), which do not support this feature and have set this flag to 0. New versions shall
all support the feature, so they have to set this flag always to 1.
[PRS_SOMEIPSD_00702] d Undefined bits within the Flag field shall be set to ’0’ when
sending and ignored on receiving. c(RS_SOMEIPSD_00002)
[PRS_SOMEIPSD_00261] d After the Flags the SOME/IP-SD Header shall have a field
of 24 bits called Reserved. c(RS_SOMEIPSD_00006)
[PRS_SOMEIPSD_00262] d After the SOME/IP-SD Header the Entries Array shall fol-
low. c(RS_SOMEIPSD_00006)
[PRS_SOMEIPSD_00263] d The entries shall be processed exactly in the order they
arrive. c(RS_SOMEIPSD_00006)

[PRS_SOMEIPSD_00264] d After the Entries Array in the SOME/IP-SD Header an

Option Array shall follow. c(RS_SOMEIPSD_00006)
[PRS_SOMEIPSD_00265] d The Entries Array and the Options Array of the SOME/IP-
SD message shall start with a length field as uint32 that counts the number of bytes of
the following data; i.e. the entries or the options. c(RS_SOMEIPSD_00006)
4.1.2.3 Entry Format
[PRS_SOMEIPSD_00266] d The service discovery shall support multiple entries that

are combined in one service discovery message. c(RS_SOMEIPSD_00006)
Note:
The entries are used to synchronize the state of services instances and the Publish/-
Subscribe handling.
[PRS_SOMEIPSD_00267] d Two types of entries exist: A Service Entry Type for Ser-
vices and an Eventgroup Entry Type for Eventgroups. c(RS_SOMEIPSD_00006)
[PRS_SOMEIPSD_00268] d A Service Entry Type shall be 16 Bytes of size and include
the following fields in this order as shown in Figure 4.1:
• Type Field [uint8]: encodes FindService (0x00) and OfferService (0x01).
• Index First Option Run [uint8]: Index of this runs first option in the option array.
• Index Second Option Run [uint8]: Index of this runs second option in the option
array.
• Number of Options 1 [uint4]: Describes the number of options the first option run
uses.
• Number of Options 2 [uint4]: Describes the number of options the second option
run uses.
• Service-ID [uint16]: Describes the Service ID of the Service or Service-Instance
this entry is concerned with.
• Instance ID [uint16]: Describes the Service Instance ID of the Service Instance
this entry is concerned with or is set to 0xFFFF if all service instances of a service
are meant.
• Major Version [uint8]: Encodes the major version of the service (instance).
• TTL [uint24]: Describes the lifetime of the entry in seconds.
• Minor Version [uint32]: Encodes the minor version of the service.

SOME/IP-SD Service Entry Type is shown in Figure 4.4 c(RS_SOMEIPSD_00006)

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
Type Index 1st options Index 2nd options # of opt 1 # of opt 2
Service ID Instance ID
Major Version TTL
Minor Version
Figure 4.4: SOME/IP-SD Service Entry Type
[PRS_SOMEIPSD_00270] d An Eventgroup Entry shall be 16 Bytes of size and include

the following fields in this order as shown in Figure 4.5:
• Type Field [uint8]: encodes Subscribe (0x06), and SubscribeAck (0x07).
• Index First Option Run [uint8]: Index of this runs first option in the option array.
• Index Second Option Run [uint8]: Index of this runs second option in the option
array.
• Number of Options 1 [uint4]: Describes the number of options the first option run
uses.
• Number of Options 2 [uint4]: Describes the number of options the second option
run uses.
• Service-ID [uint16]: Describes the Service ID of the Service or Service Instance
this entry is concerned with.
• Instance ID [uint16]: Describes the Service Instance ID of the Service Instance
this entry is concerned with or is set to 0xFFFF if all service instances of a service
are meant.
• Major Version [uint8]: Encodes the major version of the service instance this
eventgroup is part of.
• TTL [uint24]: Descibes the lifetime of the entry in seconds.
• Reserved [uint8]: Shall be set to 0x00.
• Initial Data Requested Flag [1 bit] (I Flag): Shall be set to 1, if initial data shall be
sent by Server (see [PRS_SOMEIPSD_00703]).
• Reserved2 [uint3]: Shall be set to 0x0, if not specified otherwise (see
[PRS_SOMEIPSD_00391] and [PRS_SOMEIPSD_00394]).
• Counter [uint4]: Is used to differentiate identical Subscribe Eventgroups of the
same subscriber. Set to 0x0 if not used.
• Eventgroup ID [uint16]: Transports the ID of an Eventgroup.

SOME/IP-SD Eventgroup Entry Type is shown in Figure 4.5 c(RS_SOMEIPSD_00006)
Figure 4.5: SOME/IP-SD Eventgroup Entry Type
4.1.2.3.1 Referencing Options from Entries
Using the following fields of the entries, options are referenced by the entries:
• Index First Option Run: Index into array of options for first option run. Index 0
means first of SOME/IP-SD packet.
• Index Second Option Run: Index into array of options for second option run. Index
0 means first of SOME/IP-SD packet.
• Number of Options 1: Length of first option run. Length 0 means no option in
option run.
• Number of Options 2: Length of second option run. Length 0 means no option in
option run.
Two different option runs exist: First Option Run and Second Option Run.
Rationale for the support of two option runs: Two different types of options are ex-
pected: options common between multiple SOME/IP-SD entries and options different
for each SOME/IP-SD entry. Supporting to different options runs is the most efficient
way to support these two types of options, while keeping the wire format highly efficient.
[PRS_SOMEIPSD_00341] d Each option run shall reference the first option and the
number of options for this run. c(RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00342] d If the number of options is set to zero, the option run is
considered empty. c(RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00343] d For empty runs the Index (i.e. Index First Option Run
and/or Index Second Option Run) shall be set to zero. c(RS_SOMEIPSD_00025)

4.1.2.4 Options Format
Options are used to transport additional information to the entries. This includes for
instance the information how a service instance is reachable (IP-Address, Transport
Protocol, Port Number).
[PRS_SOMEIPSD_00273] d In order to identify the option type every option shall start
with:
• Length [uint16]: Specifies the length of the option in Bytes.
• Type [uint8]: Specifying the type of the option.
[PRS_SOMEIPSD_00274] d The length field shall cover all bytes of the option except
the length field and type field. c(RS_SOMEIPSD_00006)
If another option follows an option with variable length, the 2nd option may be mis-
aligned depending on the length of the 1st option.
4.1.2.4.1 Configuration Option
The configuration option is used to transport arbitrary configuration strings. This allows
to encode additional information like the name of a service or its configuration.
[PRS_SOMEIPSD_00276] d The format of the Configuration Option shall be as follows:
• Length [uint16]: Shall be set to the total number of bytes occupied by the config-
uration option, excluding the 16 bit length field and the 8 bit type flag.
• Type [uint8]: Shall be set to 0x01.
• ConfigurationString [dyn length]: Shall carry the configuration string.
[PRS_SOMEIPSD_00277] d The Configuration Option shall specify a set of name-
value-pairs based on the DNS TXT and DNS-SD format. c(RS_SOMEIPSD_00006,
RS_SOMEIPSD_00009)
[PRS_SOMEIPSD_00278] d The format of the configuration string shall start with a
single byte length field that describes the number of bytes following this length field.
After the length field a character sequence with the specified length shall follow. c
(RS_SOMEIPSD_00006)
[PRS_SOMEIPSD_00279] d After each character sequence another length field and a
following character sequence are expected until a length field shall be set to 0x00. c
(RS_SOMEIPSD_00006)

[PRS_SOMEIPSD_00280] d After a length field is set to 0x00 no characters shall fol-

low. c(RS_SOMEIPSD_00006)
[PRS_SOMEIPSD_00281] d A character sequence shall encode a key and an option-
ally a value. c(RS_SOMEIPSD_00006)
[PRS_SOMEIPSD_00282] d The character sequences shall contain an equal charac-
ter ("=", 0x3D) to devide key and value. c(RS_SOMEIPSD_00006)
[PRS_SOMEIPSD_00283] d The key shall not include an equal character and shall
be at least one non-whitespace character. The characters of "Key" shall be printable
US-ASCII values (0x20-0x7E), excluding ’=’ (0x3D). c(RS_SOMEIPSD_00006)
[PRS_SOMEIPSD_00284] d The "=" shall not be the first character of the sequence. c
(RS_SOMEIPSD_00006)
[PRS_SOMEIPSD_00285] d For a character sequence without an ’=’ that key shall be
interpreted as present. c(RS_SOMEIPSD_00006)
[PRS_SOMEIPSD_00286] d For a character sequence ending on an ’=’ that key shall
be interpreted as present with empty value. c(RS_SOMEIPSD_00006)
[PRS_SOMEIPSD_00287] d Multiple entries with the same key in a single Configura-
tion Option shall be supported. c(RS_SOMEIPSD_00006)
[PRS_SOMEIPSD_00289] d Format of the Configuration Option shall be as shown in
Figure 4.6 c(RS_SOMEIPSD_00006)
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
Length Type (= 0x01) Reserved (= 0x00)
Covered by Length
Zero-terminated Configuration String (incl. Reserved)
([len]id=value[len]id=value[0])
Figure 4.6: SOME/IP-SD Configuration Option
Example for SOME/IP-SD Configuration Option
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
Length (=0x0010 ) Type (= 0x01) Reserved (= 0x00)

Covered by Length
[5] a b c
(incl. Reserved)
= x [7] d
e f = 1
2 3 [0]
Figure 4.7: SOME/IP-SD Configuration Option Example

4.1.2.4.2 Load Balancing Option
The Load Balancing option is used to prioritize different instances of a service, so that
a client chooses the service instance based on these settings. This option will be
attached to Offer Service entries.
[PRS_SOMEIPSD_00542] d The Load Balancing Option shall carry a Priority and
Weight like the DNS-SRV records, which shall be used for load balancing different
service instances. c(RS_SOMEIPSD_00011)
[PRS_SOMEIPSD_00711] d When looking for all service instances of a service (Ser-
vice Instance set to 0xFFFF), the client shall choose the service instance with highest
priority. c(RS_SOMEIPSD_00011)
[PRS_SOMEIPSD_00712] d When having more than one service instance with highest
priority (lowest value in Priority field) the service instance shall be chosen randomly
based on the weights of the service instances. c(RS_SOMEIPSD_00011)
[PRS_SOMEIPSD_00713] d In case if there is no Load Balancing Option avil-
able and several Service instance are offered, then the application logic shall per-
form the selection of the Service instance based on use-case specific criteria. c
(RS_SOMEIPSD_00011)
[PRS_SOMEIPSD_00544] d The Format of the Load Balancing Option shall be as
follows:
• Length [uint16]: Shall be set to 0x0005.
• Priority [uint16]: Carries the Priority of this instance. Lower value means higher
priority.
• Weight [uint16]: Carries the Weight of this instance. Large value means higher
probability to be chosen.
[PRS_SOMEIPSD_00584] d The format of the Load Balancing Op-
tion shall follow this figure: Figure 4.8 c(RS_SOMEIPSD_00011)
Figure 4.8: SOME/IP-SD Load Balancing Option

4.1.2.4.3 IPv4 Endpoint Option
The IPv4 Endpoint Option is used by a SOME/IP-SD instance to signal the relevant
endpoint(s). Endpoints include the local IP address, the transport layer protocol (e.g.
UDP or TCP), and the port number of the sender. These ports are used for the events
and notification events as well.
[PRS_SOMEIPSD_00305] d The IPv4 Endpoint Option shall use the Type 0x04. c
(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)
[PRS_SOMEIPSD_00306] d The IPv4 Endpoint Option shall specify the IPv4-Address,
the transport layer protocol (ISO/OSI layer 4) used, and its Port Number. c
[PRS_SOMEIPSD_00307] d The Format of the IPv4 Endpoint Option shall be as fol-
lows:
• IPv4-Address [uint32]: Shall transport the unicast IP-Address as four Bytes.
• Transport Protocol (L4-Proto) [uint8]: Shall be set to the transport layer protocol
(ISO/OSI layer 4) based on the IANA/IETF types (0x06: TCP, 0x11: UDP).
• Transport Protocol Port Number (L4-Port) [uint16]: Shall be set to the port of the
layer 4 protocol.
c(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)
SOME/IP-SD IPv4 Endpoint Option shall be as shown in Figure 4.9 c
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
(incl. Reserved)
IPv4-Address [32bit]
Reserved (=0x00) L4-Proto (TCP/UDP/) Port Number
Figure 4.9: SOME/IP-SD IPv4 Endpoint Option
[PRS_SOMEIPSD_00310] d The server shall use the IPv4 Endpoint Option with
Offer Service entries to signal the endpoints it serves the service on. That is
upto one UDP endpoint and upto one TCP endpoint. c(RS_SOMEIPSD_00006,
RS_SOMEIPSD_00010)

[PRS_SOMEIPSD_00380] d The endpoints the server referenced with an Offer Ser-

vice entry shall also be used as source of events. That is source IP address and
source port numbers for the transport protocols in the endpoint option. The client shall
use the IPv4 Endpoint Options with Subscribe Eventgroup entries to signal its IP ad-
dress and its UDP and/or TCP port numbers, on which it is ready to receive the events.
[PRS_SOMEIPSD_00807] d The client shall use the IPv4 Endpoint Option with Sub-
scribe Eventgroup entries to signal the IP address and the UDP and/or TCP port
numbers, on which it is ready to receive the events. c(RS_SOMEIPSD_00006,
RS_SOMEIPSD_00010)
4.1.2.4.4 IPv6 Endpoint Option
The IPv6 Endpoint Option is used by a SOME/IP-SD instance to signal the relevant
endpoint(s). Endpoints include the local IP address, the transport layer protocol (e.g.
UDP or TCP), and the port number of the sender. These ports are used for the events
and notification events as well.
[PRS_SOMEIPSD_00314] d The IPv6 Endpoint Option shall use the Type 0x06. c
lows:
• IPv6-Address [uint128]: Shall transport the unicast IP-Address as 16 Bytes.
(ISO/OSI layer 4) based on the IANA/IETF types (0x06: TCP, 0x11: UDP).
• Transport Protocol Port Number (L4-Port) [uint16]: Shall be set to the transport
layer port(e.g. 30490).
SOME/IP-SD IPv6 Endpoint Option shall be as shown in Figure 4.10 c

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
(incl. Reserved)
Reserved (=0x00) L4-Proto (TCP/UDP+) Port Number
Figure 4.10: SOME/IP-SD IPv6 Endpoint Option
[PRS_SOMEIPSD_00319] d The server shall use the IPv6 Endpoint Option with Of-
fer Service entries to signal the endpoints the services is available on. That is
upto one UDP endpoint and upto one TCP endpoint. c(RS_SOMEIPSD_00006,
RS_SOMEIPSD_00010)
[PRS_SOMEIPSD_00320] d The endpoints the server referenced with an Offer Ser-
vice entry shall also be used as source of events. That is source IP address
and source port numbers for the transport protocols in the endpoint option. c
[PRS_SOMEIPSD_00321] d The client shall use the IPv6 Endpoint Option with Sub-
scribe Eventgroup entries to signal the IP address and the UDP and/or TCP port
numbers, on which it is ready to receive the events. c(RS_SOMEIPSD_00006,
RS_SOMEIPSD_00010)
4.1.2.4.5 IPv4 Multicast Option
The IPv4 Multicast Option is used by the server to announce the IPv4 multicast ad-
dress, the transport layer protocol (ISO/OSI layer 4), and the port number the multicast
events and multicast notification events are sent to. As transport layer protocol currently
only UDP is supported.
[PRS_SOMEIPSD_00323] d The IPv4 Multicast Option shall be referenced by Sub-
scribe Eventgroup Ack entries. c(RS_SOMEIPSD_00003)
[PRS_SOMEIPSD_00324] d The IPv4 Multicast Option shall use the Type 0x14. c
(RS_SOMEIPSD_00003)
[PRS_SOMEIPSD_00325] d The IPv4 Multicast Option shall specify the IPv4-Address,
(RS_SOMEIPSD_00003)
lows:


• IPv4-Address [uint32]: Shall transport the multicast IP-Address as four Bytes.
(ISO/OSI layer 4) based on the IANA/IETF types (0x11: UDP).
layer 4 protocol.
SOME/IP-SD IPv4 Multicast Option shall be as shown in Figure 4.11 c
(RS_SOMEIPSD_00003)
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
(incl. Reserved)
Length (=0x0009 ) Type (=0x14) Reserved (=0x00)
Reserved (=0x00) L4-Proto (UDP//) Port Number
Figure 4.11: SOME/IP-SD IPv4 Multicast Option
[PRS_SOMEIPSD_00329] d The server shall reference the IPv4 Multicast Option,

which encodes the IPv4 Multicast Address and Port Number the server will send mul-
ticast events and notification events to. c(RS_SOMEIPSD_00003)
4.1.2.4.6 IPv6 Multicast Option
The IPv6 Multicast Option is used by the server to announce the IPv6 multicast ad-
dress, the layer 4 protocol, and the port number the multicast events and multicast
notifications events are sent to. For the transport layer protocol (ISO/OSI layer 4) cur-
rently only UDP is supported.
[PRS_SOMEIPSD_00331] d The IPv6 Multicast Option shall use the Type 0x16. c
(RS_SOMEIPSD_00003)
[PRS_SOMEIPSD_00332] d The IPv6 Multicast Option shall specify the IPv6-Address,
(RS_SOMEIPSD_00003)
[PRS_SOMEIPSD_00333] d The Format of the IPv6 Multicast Option shall be as fol-
lows:


• IPv6-Address [uint128]: Shall transport the multicast IP-Address as 16 Bytes.
(ISO/OSI layer 4) based on the IANA/IETF types (0x11: UDP).
layer 4 protocol.
[PRS_SOMEIPSD_00545] d The IPv6 Multicast Option and not the IPv6 End-
point Option shall be referenced by Subscribe Eventgroup Ack messages. c
(RS_SOMEIPSD_00003)
SOME/IP-SD IPv6 Multicast Option shall be as shown in Figure 4.12 c
(RS_SOMEIPSD_00003)
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
Length (=0x0015 ) Type (= 0x16) Reserved (=0x00)
Covered by Length
(incl. Reserved)
Reserved (=0x00) L4-Proto (UDP/+) Port Number
Figure 4.12: SOME/IP-SD IPv6 Multicast Option
[PRS_SOMEIPSD_00336] d The server shall reference the IPv6 Multicast Option,

which encodes the IPv6 Multicast Address and Port Number the server will send mul-
ticast events and notification events to. c(RS_SOMEIPSD_00003)
4.1.2.4.7 IPv4 SD Endpoint Option
The IPv4 SD Endpoint Option is used to transport the endpoint (i.e. IP-Address and
Port) of the senders SD implementation. This is used to identify the SOME/IP-SD
Instance even in cases in which the IP-Address and/or Port Number cannot be used.
Note:
This is used to identify the SOME/IP-SD Instance even in cases in which the IP-

Address and/or Port Number cannot be used. A use case would be a proxy service
discovery on one ECU which handles the multicast traffic for another ECU.
SOME/IP-SD IPv4 SD Endpoint Option is shown in Figure 4.13
Figure 4.13: SOME/IP-SD IPv4 SD Endpoint Option
[PRS_SOMEIPSD_00547] d The IPv4 SD Endpoint Option shall be included in any SD

message up to 1 time. c(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)
[PRS_SOMEIPSD_00650] d The IPv4 SD Endpoint Option shall only be included
if the SOME/IP-SD message is transported over IPv4. c(RS_SOMEIPSD_00006,
RS_SOMEIPSD_00010)
[PRS_SOMEIPSD_00651] d The IPv4 SD Endpoint Option shall be the first option in
the options array, if existing. c(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)
[PRS_SOMEIPSD_00548] d The IPv4 SD Endpoint Option shall be not referenced by
any SD Entry. c(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)
[PRS_SOMEIPSD_00549] d If the IPv4 SD Endpoint Option is included in the
SD message, the receiving SD implementation shall use the content of this op-
tion instead of the Source IP Address and Source Port. c(RS_SOMEIPSD_00006,
RS_SOMEIPSD_00010)
Note:
This is important for answering the received SD message (e.g. Offer after Find or
Subscribe after Offer or Subscribe Ack after Subscribe) as well as the reboot detection
(channel based on SD Endpoint Option and not out addresses).
[PRS_SOMEIPSD_00550] d The IPv4 SD Endpoint Option shall use the Type 0x24. c
[PRS_SOMEIPSD_00551] d The IPv4 SD Endpoint Option shall specify the IPv4-
Address, the transport layer protocol (ISO/OSI layer 4) used, and a Port Number. c
[PRS_SOMEIPSD_00552] d The Format of the IPv4 SD Endpoint Option shall be as
follows:
• IPv4-Address [uint32]: Shall transport the unicast IP-Address of SOME/IP-SD as
four Bytes.


of SOME/IP-SD (currently: 0x11 UDP).
layer port of SOME/IP-SD (currently: 30490).
4.1.2.4.8 IPv6 SD Endpoint Option
The Ipv6 SD Endpoint Option is used to transport the endpoint (i.e. IP-Address and
Port) of the senders SD implementation. This is used to identify the SOME/IP-SD
Instance even in cases in which the IP-Address and/or Port Number cannot be used.
SOME/IP-SD IPv6 SD Endpoint Option is shown in Figure 4.14
Note:
A use case would be a proxy service discovery on one ECU which handles the multi-
cast traffic for another ECU.
Figure 4.14: SOME/IP-SD IPv6 SD Endpoint Option

RS_SOMEIPSD_00010)
[PRS_SOMEIPSD_00554] d The IPv6 SD Endpoint Option may be included in any SD
message up to 1 time. c(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)
RS_SOMEIPSD_00010)
[PRS_SOMEIPSD_00654] d The IPv6 SD Endpoint Option shall be the first option in
the options array, if existing. c(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)
[PRS_SOMEIPSD_00555] d The IPv6 SD Endpoint Option shall be not referenced by
any SD Entry. c(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)

[PRS_SOMEIPSD_00556] d If the IPv6 SD Endpoint Option is included in the SD

message, the receiving SD implementation shall use the content of this option in-
stead of the Source IP Address and Source Port for answering this SD messages.
[PRS_SOMEIPSD_00557] d The IPv6 SD Endpoint Option shall use the Type 0x26. c
[PRS_SOMEIPSD_00558] d The IPv6 SD Endpoint Option shall specify the IPv6-
Address, the transport layer protocol (ISO/OSI layer 4) used, and its Port Number.
[PRS_SOMEIPSD_00559] d The Format of the IPv6 SD Endpoint Option shall be as
follows:
• IPv6-Address [uint128]: Shall transport the unicast IP-Address of SOME/IP-SD
as 16 Bytes.
of SOME/IP-SD (currently: 0x11 UDP).
layer port of SOME/IP-SD (currently: 30490).
4.1.2.5 Service Entries
4.1.2.5.1 Find Service Entry
[PRS_SOMEIPSD_00350] d The Find Service entry type shall be used for finding
service instances and shall only be sent if the current state of a service is unknown
(no current Service Offer was received and is still valid). c(RS_SOMEIPSD_00008,
RS_SOMEIPSD_00021)
[PRS_SOMEIPSD_00351] d Find Service entries shall set the entry fields in the fol-
lowing way:
• Type shall be set to 0x00 (FindService).
• Service ID shall be set to the Service ID of the service that shall be found.

• Instance ID shall be set to 0xFFFF, if all service instances shall be returned. It

shall be set to the Instance ID of a specific service instance, if just a single service
instance shall be returned.
• Major Version shall be set to 0xFF, that means that services with any version shall
be returned. If set to value different than 0xFF, services with this specific major
version shall be returned only.
• Minor Version shall be set to 0xFFFF FFFF, that means that services with any
version shall be returned. If set to a value different to 0xFFFF FFFF, services
with this specific minor version shall be returned only.
• TTL shall be set to the lifetime of the Find Service entry. After this lifetime the
Find Service entry shall be considered not existing.
• If TTL is set to 0xFFFFFF, the Find Service entry shall be considered valid until
the next reboot.
• TTL shall not be set to 0x000000 since this is considered to be the Stop Offer
Service Entry.
[PRS_SOMEIPSD_00528] d A sender shall not reference Endpoint Options
nor Multicast Options in a Find Service Entry. c(RS_SOMEIPSD_00008,
RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00529] d A receiver shall ignore Endpoint Options and Multicast
Options in a Find Service Entry. c(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00530] d Other Options (neither Endpoint nor Multicast Options),
shall still be allowed to be used in a Find Service Entry. c(RS_SOMEIPSD_00013,
RS_SOMEIPSD_00025)
4.1.2.5.2 Offer Service Entry
[PRS_SOMEIPSD_00355] d The Offer Service entry type shall be used to offer a ser-
vice to other communication partners. c(RS_SOMEIPSD_00013)
[PRS_SOMEIPSD_00356] d Offer Service entries shall set the entry fields in the fol-
lowing way:
• Type shall be set to 0x01 (OfferService).
• Service ID shall be set to the Service ID of the service instance offered.
• Instance ID shall be set to the Instance ID of the service instance that is offered.
• Major Version shall be set to the Major Version of the service instance that is
offered.

• Minor Version shall be set to the Minor Version of the service instance that is
offered.
• TTL shall be set to the lifetime of the service instance. After this lifetime the
service instance shall considered not been offered.
• If TTL is set to 0xFFFFFF, the Offer Service entry shall be considered valid until
the next reboot.
• TTL shall not be set to 0x000000 since this is considered to be the Stop Offer
Service Entry.
[PRS_SOMEIPSD_00357] d Offer Service entries shall always reference at least
an IPv4 or IPv6 Endpoint Option to signal how the service is reachable. c
[PRS_SOMEIPSD_00358] d For each Transport Layer Protocol needed for the service
(i.e. UDP and/or TCP) an IPv4 Endpoint option shall be added if IPv4 is supported. c
[PRS_SOMEIPSD_00359] d For each Transport Layer Protocol needed for the service
(i.e. UDP and/or TCP) an IPv6 Endpoint option shall be added if IPv6 is supported. c
4.1.2.5.3 Stop Offer Service Entry
[PRS_SOMEIPSD_00363] d The Stop Offer Service entry type shall be used to stop
offering service instances. c(RS_SOMEIPSD_00014)
[PRS_SOMEIPSD_00364] d Stop Offer Service entries shall set the entry fields exactly
like the Offer Service entry they are stopping, except:
• TTL shall be set to 0x000000.
4.1.2.5.4 Usage of Options in Entries
Table 4.1 shall show the SOME/IP-SD Option types in relation to Entry types which are
allowed:
c(RS_SOMEIPSD_00025, RS_SOMEIPSD_00008, RS_SOMEIPSD_00013,
RS_SOMEIPSD_00014, RS_SOMEIPSD_00015, RS_SOMEIPSD_00016)
Endpoint Multicast Configuration Load Balanc-

ing

FindService 0 0 0-1 0-1

OfferService 1-2 0 0-1 0-1
StopOffer Service 1-2 0 0-1 0-1
Subscribe Event- 1-2 0 0-1 0-1
group
StopSubscribe 1-2 0 0-1 0-1
Eventgroup
Subscribe Event- 0 0-1 0-1 0-1
groupAck
Subscribe Event- 0 0 0-1 0-1
groupNack
Table 4.1: Allowed Option Types for Entry Types
4.1.2.6 Endpoint Handling for Services and Events
[PRS_SOMEIPSD_00476] d The Service Discovery shall overwrite IP Addresses and

Port Numbers with those transported in Endpoint and Multicast Options if the statically
configured values are different from those in these options. c(RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00360] d The IP addresses and port numbers of the Endpoint
Options shall also be used for transporting events and notification events. c
[PRS_SOMEIPSD_00361] d In case of UDP the endpoint option shall be used for
the source address and the source port of the events and notification events, it is
also the address the client can send method requests to. c(RS_SOMEIPSD_00013,
RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00362] d In case of TCP the endpoint option shall be used for the
IP address and port the client needs to open a TCP connection in order to receive
events using TCP. c(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00801] d SOME/IP shall allow services to use UDP and TCP at the
same time. c(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00802] d Which message is sent by which underlying transport pro-
tocol shall be determined by configuration: A Service can use UDP and TCP endpoints
at the same time. But per element of the service it shall to be configured whether TCP
or UDP is used. c(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)
Note: It needs to be restricted in the configuration which methods and which events
are provided over TCP/UDP. This also means that the same event can not be provided
over TCP and UDP.

4.1.2.6.1 Service Endpoints
The referenced Endpoint Options of the Offer Service entries denotes the
• IP Address and Port Numbers the service instance is reachable at the server.
• IP Address and Port Numbers the service instance sends the events from.
[PRS_SOMEIPSD_00480] d Events of this service instance shall not be sent from any
other Endpoints than those given in the Endpoint Options of the Offer Service entries.
[PRS_SOMEIPSD_00481] d If an ECU offers multiple service instances, SOME/IP
messages of these service instances shall be differentiated by the information
transported in the Endpoint Options referenced by the Offer Service entries. c
4.1.2.6.2 Eventgroup Endpoints
[PRS_SOMEIPSD_00484] d The Endpoint Options referenced in the Subscribe Event-

group entries shall also be used to send unicast UDP or TCP SOME/IP events for this
Service Instance. c(RS_SOMEIPSD_00015, RS_SOMEIPSD_00025)
Thus the Endpoint Options referenced in the Subscribe Eventgroup entries are the IP
Address and the Port Numbers on the client side.
[PRS_SOMEIPSD_00486] d TCP events are transported using the TCP connection
the client has opened to the server before sending the Subscribe Eventgroup entry.
See Chapter 4.1.2.4.3. c(RS_SOMEIPSD_00015, RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00487] d The initial events shall be transported using unicast from
Server to Client. c(RS_SOMEIPSD_00015, RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00488] d Subscribe Eventgroup Ack entries shall reference
up to 1 Multicast Option for the Internet Protocol used (IPv4 or IPv6). c
[PRS_SOMEIPSD_00489] d The Multicast Option shall be set to UDP as transport
protocol. c(RS_SOMEIPSD_00015, RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00490] d The client shall open the Endpoint specified in the Multi-
cast Option referenced by the Subscribe Eventgroup Ack entry as fast as possible to
not miss multicast events. c(RS_SOMEIPSD_00015, RS_SOMEIPSD_00025)
Example: Figure 4.15 shows an example with the different Endpoint and a Multicast
Option:
• The Server offers the Service Instance on Server UDP-Endpoint SU and Server
TCP-Endpoint ST
• The Client opens a TCP connection

• The Client sends a Subscribe Eventgroup entry with Client UDP-Endpoint CU

(unicast) and a Client TCP-Endpoint CT.
• The Server answers with a Subscribe Eventgroup Ack entry with Multicast MU
Then the following operations happen:
• The Client calls a method on the Server
• Request is sent from CU to SU and Response from SU to CU
• For TCP this would be: Request dyn to ST and RESPONSE from ST to CT
• The Server sends a Unicast UDP Event: SU to CU
• The Server sends a Unicast TCP Event: ST to CT
• The Server sends a Multicast UDP Event: SU to MU
Keep in mind that Multicast Endpoints use a Multicast IP Address on the receiver side,
i.e. the client, and TCP cannot be used for Multicast communication.
Figure 4.15: Publish/Subscribe Example for Endpoint Options and the usage of ports

4.1.3 Service Discovery Messages
[PRS_SOMEIPSD_00600] d All SD Messages shall be sent to SD_PORT. c(

RS_SOMEIPSD_00001)
[PRS_SOMEIPSD_00601] d SD_PORT shall be used as the source port for SD Uni-
cast/Multicast Messages. c(RS_SOMEIPSD_00002, RS_SOMEIPSD_00003)
[PRS_SOMEIPSD_00602] d All unicast SD messages should have SD_PORT
as destination port unless the SD Endpoint Option defines a different port. c
(RS_SOMEIPSD_00002)
[PRS_SOMEIPSD_00603] d All SD multicast messages shall be sent using the
SD_MULTICAST_IP. c(RS_SOMEIPSD_00003, RS_SOMEIPSD_00022)
Using the previously specified header format, different entries and messages consist-
ing of one or more entries can be built. The specific entries and their header layouts
are explained in the following sections.
4.1.3.1 Eventgroup Entry
4.1.3.1.1 Subscribe Eventgroup Entry
[PRS_SOMEIPSD_00385] d The Subscribe Eventgroup entry type shall be used to

subscribe to an eventgroup. c(RS_SOMEIPSD_00015)
[PRS_SOMEIPSD_00386] d Subscribe Eventgroup entries shall set the entry fields in
the following way:
• Type shall be set to 0x06 (SubscribeEventgroup).
• Service ID shall be set to the Service ID of the service instance that includes the
eventgroup subscribed to.
• Instance ID shall be set to the Instance ID of the service instance that includes
the eventgroup subscribed to.
• Major Version shall be set to the Major Version of the service instance of the
• Eventgroup ID shall be set to the Eventgroup ID of the eventgroup subscribed to.
• Minor Version shall be set to the Minor Version of the service instance of the
• TTL shall be set to the lifetime of the subscription.
– If set to 0xFFFFFF, the Subscribe Eventgroup entry shall be considered valid
until the next reboot.

– TTL shall not be set to 0x000000 since this is considered to be the Stop
Offer Service Entry.
• Reserved shall be set to 0x00 until further notice.
• Initial Data Requested Flag shall be set to 1, if the client sends the first subscribe
in sequence to trigger the sending of initial events. Set to 0 otherwise.
• Reserved2 shall be set to three 0 bits.
• Counter shall be used to differentiate between parallel subscribes to the same
eventgroup of the same service (only difference in endpoint). If not used, set to
0x0.
[PRS_SOMEIPSD_00387] d Subscribe Eventgroup entries shall reference one or
two IPv4 and/or one or two IPv6 Endpoint Options (one for UDP, one for TCP). c
4.1.3.1.2 Stop Subscribe Eventgroup Entry
[PRS_SOMEIPSD_00388] d The Stop Subscribe Eventgroup entry type shall be used

to stop subscribing to eventgroups. c(RS_SOMEIPSD_00017)
[PRS_SOMEIPSD_00389] d Stop Subscribe Eventgroup entries shall set the entry
fields exactly like the Subscribe Eventgroup entry they are stopping, except:
• TTL shall be set to 0x000000.
[PRS_SOMEIPSD_00574] d A Stop Subscribe Eventgroup Entry shall reference the
same options the Subscribe Eventgroup Entry referenced. This includes but is not
limited to Endpoint and Configuration options. c(RS_SOMEIPSD_00017)
4.1.3.1.3 Subscribe Eventgroup Acknowledgement (Subscribe Eventgroup

Ack) Entry
[PRS_SOMEIPSD_00390] d The Subscribe Eventgroup Acknowledgment entry type

shall be used to indicate that Subscribe Eventgroup entry was accepted. c
(RS_SOMEIPSD_00015)
[PRS_SOMEIPSD_00391] d Subscribe Eventgroup Acknowledgment entries shall set
the entry fields in the following way:
• Type shall be set to 0x07 (SubscribeEventgroupAck).

• Service ID, Instance ID, Major Version, Eventgroup ID, TTL, Reserved, Initial Data
Requested Flag, Reserved2, and Counter shall be the same value as in the Sub-
scribe Eventgroup that is being answered.
[PRS_SOMEIPSD_00392] d Subscribe Eventgroup Ack entries referencing events and
notification events that are transported via multicast shall reference an IPv4 Multicast
Option and/or and IPv6 Multicast Option. c(RS_SOMEIPSD_00015)
4.1.3.1.4 Subscribe Eventgroup Negative Acknowledgement (Subscribe Event-

group Nack) Entry
[PRS_SOMEIPSD_00393] d The Subscribe Eventgroup Negative Acknowledgment

entry type shall be used to indicate that Subscribe Eventgroup entry was NOT ac-
cepted. c(RS_SOMEIPSD_00015)
[PRS_SOMEIPSD_00394] d Subscribe Eventgroup Negative Acknowledgment entries
shall set the entry fields in the following way:
• Type shall be set to 0x07 (SubscribeEventgroupAck).
• Service ID, Instance ID, Major Version, Eventgroup ID, Counter, and Reserved
shall be the same value as in the Subscribe that is being answered.
• The TTL shall be set to 0x000000.
[PRS_SOMEIPSD_00566] d Reasons to not accept a Subscribe Eventgroup include
(but are not limited to):
• Combination of Service ID, Instance ID, Eventgroup ID, and Major Version is un-
known
• Required TCP-connection was not opened by client
• Problems with the references options occurred
• Resource problems at the Server
[PRS_SOMEIPSD_00527] d When the client receives a SubscribeEventgroupNack as
answer on a SubscribeEventgroup for which a TCP connection is required, the client
shall check the TCP connection and shall restart the TCP connection if needed. c
(RS_SOMEIPSD_00015)
Rational:
The server might have lost the TCP connection and the client has not.
Checking the TCP connection might include the following:

• Checking whether data is received for e.g. other Eventgroups.

• Sending out a Magic Cookie message and waiting for the TCP ACK.
• Reestablishing the TCP connection.
4.1.4 Service Discovery Communication Behavior
[PRS_SOMEIPSD_00800] d SOME/IP Service Discovery shall reduce the number

of Service Discovery messages by packing entries together whenever possible. c
(RS_SOMEIPSD_00025)
4.1.4.1 Startup Behavior
[PRS_SOMEIPSD_00395] d For each Service Instance or Eventgroup the Service Dis-

covery shall have at least these three phases in regard to sending entries:
• Initial Wait Phase
• Repetition Phase
• Main Phase
Note:
An actual implemented state machine will need more than just states for these three
phases. E.g. local services can be still down and remote services can be already
known (no finds needed anymore).
[PRS_SOMEIPSD_00397] d The service discovery shall enter the Initial Wait Phase for
a client service instance when the link on the interface needed for this service instance
is up and the client service is requested by the application. c(RS_SOMEIPSD_00025,
RS_SOMEIPSD_00012)
[PRS_SOMEIPSD_00133] d The service discovery shall enter the Initial Wait Phase
for a server service instance when the link on the interface needed for this ser-
vice instance is up and the server service is available. c(RS_SOMEIPSD_00025,
RS_SOMEIPSD_00012)
Note:
It is possible that the link is up but the service is not yet available on server side
Systems has started means here the needed applications and possible external sen-
sors and actuators as well. Basically the functionality needed by this service instance
has to be ready to offer a service and finding a service is applicable after some appli-
cation requires it.

[PRS_SOMEIPSD_00399] d The Service Discovery shall wait based on the INI-

TIAL_DELAY after entering the Initial Wait Phase and before sending the first mes-
sages for the Service Instance. c(RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00400] d INITIAL_DELAY shall be defined as a minimum and a
maximum delay. c(RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00401] d The wait time shall be determined by choosing
a random value between the minimum and maximum of INITIAL_DELAY. c
(RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00402] d The Service Discovery shall use the same random value
for
• Multiple entries of different types in order to pack them together for a reduced
number of messages.
• Different service instances so that it can pack multiple offers together.
[PRS_SOMEIPSD_00403] d SOME/IPService Discovery shall pack entries together,
when no random delay is involved but the messages can be sent at the same time. c
(RS_SOMEIPSD_00025)
For example shall all Subscribe Eventgroup entries of a message be answered together
in one message.
[PRS_SOMEIPSD_00404] d After sending the first message the Repetition Phase of
this Service Instance/these Service Instances is entered. c(RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00405] d The Service Discovery shall wait in the Repetitions Phase
based on REPETITIONS_BASE_DELAY. c(RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00406] d After each message sent in the Repetition Phase the de-
lay is doubled. c(RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00407] d The Service Discovery shall send out only up to REPE-
TITIONS_MAX entries during the Repetition Phase. c(RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00408] d Sending Find entries shall be stopped after receiving the
corresponding Offer entries by jumping to the Main Phase in which no Find entries are
sent. c(RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00409] d If REPETITIONS_MAX is set to 0, the Repetition Phase
shall be skipped and the Main Phase is entered for the Service Instance after the Initial
Wait Phase. c(RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00410] d After the Repetition Phase the Main Phase is being en-
tered for a Service Instance. c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00411] d After entering the Main Phase, the provider shall

wait 1*CYCLIC_OFFER_DELAY before sending the first offer entry message. c
(RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00412] d In the Main Phase Offer Messages shall be sent cyclically
if a CYCLIC_OFFER_DELAY is configured. c(RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00413] d After a message for a specific Service Instance the Ser-
vice Discovery waits for 1*CYCLIC_OFFER_DELAY before sending the next message
for this Service Instance. c(RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00415] d For Find entries (Find Service and Find Eventgroup) no
cyclic messages are allowed in Main Phase. c(RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00582] d Subscribe EventGroup Entries shall be triggered by Offer
entries, which are sent cyclically. c(RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00416] d Example:
Initial Wait Phase:
• Wait for random_delay in Range(INITIAL_DELAY_MIN, _MAX)
• Send message (Find Service and Offer Service entries)
Repetition Phase (REPETITIONS_BASE_DELAY=100ms, REPETITIONS_MAX=2):
• Wait 20 ∗ 100ms
• Wait 21 ∗ 100ms
Main Phase (as long message is active and CYCLIC_OFFER_DELAY is defined):
• Wait CYCLIC_OFFER_DELAY
• Send message (Offer Service entries)
4.1.4.2 Server Answer Behavior
[PRS_SOMEIPSD_00417] d The Service Discovery shall delay answers to entries that

were received in multicast SOME/IP-SD messages using the configuration item RE-
QUEST_RESPONSE_DELAY. This is valid for the following two cases:
• Offer entry (unicast or multicast) after received find entry (multicast)
• Subscribe entry (unicast) after received offer entry (multicast)

[PRS_SOMEIPSD_00419] d The REQUEST_RESPONSE_DELAY shall not apply if

unicast messages are answered with unicast messages. c(RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00420] d REQUEST_RESPONSE_DELAY shall be specified by a
minimum and a maximum. c(RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00421] d The actual delay shall be randomly chosen between min-
imum and maximum of REQUEST_RESPONSE_DELAY. c(RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00422] d For basic implementations all Find Service entries (no
matter of the state of the Unicast Flag) shall be answered with Offer Service entries
transported using unicast. c(RS_SOMEIPSD_00025)
[PRS_SOMEIPSD_00423] d For optimization purpose the following behaviors shall be
supported as option:
• Find messages received with the Unicast Flag set to 1 in main phase, shall
be answered with a unicast response if the last offer was sent less than
1/2 CYCLIC_OFFER_DELAY ago.
• Find messages received with the Unicast Flag set to 1 in main phase,
shall be answered with a multicast RESPONSE if the last offer was sent
1/2 CYCLIC_OFFER_DELAY or longer ago.
• Find messages received with Unicast Flag set to 0 (multicast), shall be answered
with a multicast response. (Note: this was only needed in earlier migration sce-
narios and will go away in the future)
4.1.4.3 Shutdown Behavior
[PRS_SOMEIPSD_00427] d When a server service instance of an ECU is in the Rep-

etition and Main Phase and is being stopped, a Stop Offer Service entry shall be sent
out. c(RS_SOMEIPSD_00017, RS_SOMEIPSD_00012)
[PRS_SOMEIPSD_00751] d When the link goes down for a server service instance
in the Initial Wait Phase, Repetition Phase or Main Phase, the service discovery shall
enter the Initial Wait Phase when the link is up again and the service is still available. c
(RS_SOMEIPSD_00017)
[PRS_SOMEIPSD_00752] d When the link goes down for a client service instance in
the Initial Wait Phase, Repetition Phase or Main Phase, the service discovery shall
enter the Initial Wait Phase when the link is up again and the service is still requested.
[PRS_SOMEIPSD_00428] d When a server sends out a Stop Offer Service entry
all subscriptions for this service instance shall be deleted on the server side. c
(RS_SOMEIPSD_00017)

[PRS_SOMEIPSD_00429] d When a client receives a Stop Offer Service entry

all subscriptions for this service instance shall be deleted on the client side. c
(RS_SOMEIPSD_00017)
[PRS_SOMEIPSD_00430] d When a client receives a Stop Offer Service entry, the
client shall not send out Find Service entries but wait for Offer Service entry or
change of status (application, network management, Ethernet link, or similar). c
(RS_SOMEIPSD_00017)
[PRS_SOMEIPSD_00431] d When a client service instance of an ECU is in the
Main Phase and is being stopped (i.e. the service instance is released), the SD
shall send out Stop Subscribe Eventgroup entries for all subscribed Eventgroups. c
(RS_SOMEIPSD_00017)
[PRS_SOMEIPSD_00432] d When the whole ECUs is being shut down Stop Offer
Service entries shall be sent out for all service entries and Stop Subscribe Eventgroup
entries for Eventgroups. c(RS_SOMEIPSD_00017)
4.1.4.4 State Machines
[PRS_SOMEIPSD_00433] d In this section the state machines of the client and server
are shown. c(RS_SOMEIPSD_00025)
SOME/IP Service State Machine Server is shown in Figure 4.16 c
(RS_SOMEIPSD_00025)

stm SD Serv er State Machine (Serv ices)
SD Serv er State Machine (Serv ices)

Initial [ifstatus!=up_and_configured
or service-status==down] Not Ready
[ifstatus==up_and_configured
and service-status==up] if-status-changed [ifstatus!=up_and_configured]
/clearAllTimers()
if-status-changed() or service-status-changed()
service-status==down
[ifstatus==up_and_configured and
/clearAllTimers()
service-status==up]
send(StopOfferService)
Ready
Initial Wait Phase
Initial
Timer set
Initial SetTimerInRange(INITIAL_DELAY_MIN,
INITIAL_DELAY_MAX)
Timer expired
/send(OfferService)
Repetition Phase
[REPETITIONS_MAX>0] receive(FindService)
/run=0 /waitAndSend(OfferService)
setTimer((2^run)*REPETITIONS_BASE_DELAY) ResetTimer()
Timer set
Initial
Timer expired [run<REPETITIONS_MAX]
/send(OfferService)
run++
setT imer((2^run)*REPETITIONS_BASE_DELAY)
T imer expired
[REPET ITIONS_MAX==0]
[run==REPETITIONS_MAX]
Main Phase
Initial Timer set
/setTimer(CYCLIC_ANNOUNCE_DELAY)
send(OfferService)
T imer expired
/setTimer(CYCLIC_ANNOUNCE_DELAY) receive(FindService)
send(OfferService) /waitAndSend(OfferService)
resetTimer()
Figure 4.16: SOME/IP Service State Machine Server

SOME/IP Service State Machine Client is shown in Figure 4.17 c

(RS_SOMEIPSD_00025)
Figure 4.17: SOME/IP Service State Machine Client
4.1.4.5 SOME/IP-SD Mechanisms and Errors
In this section SOME/IP-SD in cases of errors (e.g. lost or corrupted packets) is dis-
cussed. This is also be understood as rationale for the mechanisms used and the
configuration possible.

Soft State Protocol: SOME/IP-SD was designed as soft state protocol, that means that
entries come with a lifetime and need to be refreshed to stay valid (setting the TTL to
the maximum value shall turn this off).
Initial Wait Phase:
The Initial Wait Phase was introduced for two reasons: deskewing events of starting
ECUs to avoid traffic bursts and allowing ECUs to collect multiple entries in SD mes-
sages.
Repetition Phase:
The Repetition Phase was introduced to allow for fast synchronization of clients and
servers. If the clients startup later, it will find the server very fast. And if the server
starts up later, the client can be found very fast. The Repetition Phase increases the
time between two messages exponentially to avoid that overload situtaions keep the
system from synchronization.
Main Phase:
In the Main Phase the SD tries to stabilize the state and thus decreases the rate of
packets by sending no Find Services anymore and only offers in the cyclic interval
(e.g. every 1s).
Request-Response-Delay:
SOME/IP-SD shall be configured to delay the answer to entries in multicast messages
by the Request-Response-Delay. This is useful in large systems with many ECUs.
When sending a SD message with many entries in it, a lot of answers from different
ECUs arrive at the same time and put large stress on the ECU receiving all these
answers.

4.1.4.6 Error Handling
Figure 4.18: SOME/IP-SD Error Handling

Figure 4.18 shows a simplified process for the error handling of incoming SOME/IP-SD
messages.
[PRS_SOMEIPSD_00124] d For error handling of incoming SOME/IP-SD
messages, Execute the checks described in ([PRS_SOMEIPSD_00125],
[PRS_SOMEIPSD_00126], [PRS_SOMEIPSD_00127], [PRS_SOMEIPSD_00128],
[PRS_SOMEIPSD_00129], [PRS_SOMEIPSD_00803], [PRS_SOMEIPSD_00130],
[PRS_SOMEIPSD_00131], [PRS_SOMEIPSD_00132]). If at least one of these
checks fails, you need to:
• Answer with a Subscribe Eventgroup NACK, if the original entry was a Subscribe
Eventgroup entry
• Ignore, if the original entry was not a Subscribe Eventgroup entry
[PRS_SOMEIPSD_00125] d Check that at least enough bytes for an empty
SOME/IP-SD message are present, i.e the message is at least 12 Bytes long. c
(RS_SOMEIPSD_00019)
[PRS_SOMEIPSD_00126] d Check if the Service ID is known c
(RS_SOMEIPSD_00019)
[PRS_SOMEIPSD_00127] d Check if the Instance ID of this Service ID is known c
(RS_SOMEIPSD_00019)
[PRS_SOMEIPSD_00128] d Check if the Major Version of this Service Instance is
known c(RS_SOMEIPSD_00019)
[PRS_SOMEIPSD_00129] d Check if the Eventgroup ID of the Service In-
stance with Major Version is known (only applicable for eventgroup entries) c
(RS_SOMEIPSD_00019)
[PRS_SOMEIPSD_00803] d Check that the length of the Entries Array has a valid size.
[PRS_SOMEIPSD_00130] d Check if the referenced Options exist in the options array
and are syntactically ok:
• Length of Options Array is consistent
• if number of opt1 equals 0, the Index 1st options also equals 0
• if number of opt2 equals 0, the Index 2nd options also equals 0
• Option Type is known
• Option Length is consistent
• Option is valid for entry
• Endpoint Options with valid L4-Protocol field

[PRS_SOMEIPSD_00131] d Check if the TCP connection is already present (only ap-

plicable, if TCP is configured for Eventgroup and Subscribe Eventgroup entry was re-
ceived) c(RS_SOMEIPSD_00019)
[PRS_SOMEIPSD_00132] d Check if enough resources are left (e.g. Socket Connec-
tions) c(RS_SOMEIPSD_00019)
4.1.5 Announcing non-SOME/IP protocols with SOME/IP-SD
Besides SOME/IP other communication protocols are used within the vehicle; e.g. for
Network Management, Diagnosis, or Flash Updates. Such communication protocols
might need to communicate a service instance or have eventgroups as well.
[PRS_SOMEIPSD_00437] d For Non-SOME/IP protocols (the application protocol it-
self doesn’t use SOME/IP but it is published over SOME/IP SD) a special Service-ID
shall be used and further information shall be added using the configuration option:
• Service-ID shall be set to 0xFFFE (reserved)
• Instance-ID shall be used as described for SOME/IP services and eventgroups.
• The Configuration Option shall be added and shall contain exactly one entry with
key "otherserv" and a configurable non-empty value that is determined by the
system department.
[PRS_SOMEIPSD_00438] d SOME/IP services shall not use the otherserv-string in
the Configuration Option. c(RS_SOMEIPSD_00004)
[PRS_SOMEIPSD_00439] d For Find Service/Offer Service/Request Service entries
the otherserv-String shall be used when announcing non-SOME/IP service instances.
Example for valid otherserv-string: "otherserv=internaldiag".
Example for an invalid otherserv-string: "otherserv".
Example for an invalid otherserv-string: "otherserv=". c(RS_SOMEIPSD_00004)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 bit offset
Message ID (Service ID / Method ID ) [32 bit]
(= 0xFFFF 8100 )
Length [32 bit]
SOME/IP
= 0x0000 005 C (92)
Request ID (Client ID / Session ID) [32 bit]
Protocol Version [8 bit] Interface Version [8 bit] Message Type [8 bit] Return Code [8 bit]
=0x01 =0x01 =0x02 =0x00
Flags [8 bit] = 0x80 Reserved [8 bit =0x00]
Length of Entries Array in Bytes [32 bit]

=0x0000 0020 (32)
=0x00 (Find) =0 =0 =0 (none) = 0 (none )
=0x1001 =0xFFFF (all)
Major Version TTL
=0xff (any ) =3600 (search is valid for 1h)
Minor Version
=0xFFFF FFFF (any)
Example: =0x01 (Offer) =0 =0 =2 =0 (none )
=0xFFFE =0x0001
SOME/IP SD
Major Version TTL
=0x01 =3 (offer is valid for 3 seconds )
Minor Version
=0x00000032
Length of Options Array in Bytes
= 0x0000 0028 (40)
Length Type Reserved
=0x0009 =0x04 (IPv4 Endpoint ) =0x00
IPv4-Address = 192.168 .0.1
Reserved L4-Proto Port Number

=0x00 =0x06 (TCP) =0x1A91 (Port 6801 )
Length Type Reserved
=0x0025 =0x01 (Config) =0x00
[0x16]otherserv =internaldiag [0]
Figure 4.19: SOME/IP-SD Example PDU for Non-SOME/IP-SD

4.1.6 Publish/Subscribe with SOME/IP and SOME/IP-SD
Note: In contrast to the SOME/IP request/response mechanism there may be cases in

which a client requires a set of parameters from a server, but does not want to request
that information each time it is required. These are called notifications and concern
events and fields.
[PRS_SOMEIPSD_00443] d All clients needing events and/or notification events shall
register using the SOME/IP-SD at run-time with a server. c(RS_SOMEIPSD_00013,
The Notification Interaction sequence is as shown below.
Client Server
SOME/IP-SD: SubscribeEventgroup ()
SOME/IP-SD: SubscribeEventgroupAck ()
SOME/IP: Event()
SOME/IP: Event()
SOME/IP: Event()
SOME/IP: Event()
Figure 4.20: Notification interaction
This feature is comparable but NOT identical to the MOST notification mechanism.
[PRS_SOMEIPSD_00446] d With the SOME/IP-SD entry Offer Service the server
offers to push notifications to clients; thus, it shall be used as trigger for Subscrip-
tions. c(RS_SOMEIPSD_00013, RS_SOMEIPSD_00014, RS_SOMEIPSD_00015,
RS_SOMEIPSD_00016)
[PRS_SOMEIPSD_00449] d Each client shall respond to a SOME/IP-SD Offer Service
entry from the server with a SOME/IP-SD Subscribe Eventgroup entry as long as the
client is still interested in receiving the notifications/events of this eventgroup.
If the client is able to reliably detect the reboot of the server using the SOME/IP-SD
messages reboot flag, the client may choose to only answer Offer Service messages
after the server reboots if configured to do so (TTL set to maximum value). The client
make sure that this works reliable even when the SOME/IP-SD messages of the server
are lost. c(RS_SOMEIPSD_00015)
[PRS_SOMEIPSD_00703] d The client shall explicitly request Initial Events by setting
the Initial Data Requested Flag, if it has no active subscription to the Eventgroup. c
(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00704] d If the client sends out additional Subscribe Eventgroup

entries and the TTL of the previous Subscribe has not expired, then the client shall not
request Initial Events. c(RS_SOMEIPSD_00015, RS_SOMEIPSD_00020)
Reasons for the client to explicitly request Initial Events include but are not limited to:
• The client is currently not subscribed to the Eventgroup.
• The client has seen a link-down/link-up after the last Subscribe Eventgroup entry.
• The client has not received a Subscribe Eventgroup Ack after the last regular
Subscribe Eventgroup
• The client has detected a Reboot of the Server of this Services
[PRS_SOMEIPSD_00570] d If the client subscribes to two or more eventgroups includ-
ing one or more identical events or fields, the server shall not send duplicated events
or notification events for the field. This does mean regular events and not initial events.
Publish/Subscribe with link loss at client is as shown in Figure 4.21 c
(RS_SOMEIPSD_00015)

Figure 4.21: Publish/Subscribe with link loss at client (figure ignoring timings)
Note: The server sending Offer Service entries as implicit Publishes has to keep state
of Subscribe Eventgroup messages for this eventgroup instance in order to know if
notifications/events have to be sent.
[PRS_SOMEIPSD_00452] d A client shall deregister from a server by sending a
SOME/IP-SD Subscribe Eventgroup message with TTL=0 (Stop Subscribe Eventgroup
see [PRS_SOMEIPSD_00389]). c(RS_SOMEIPSD_00017, RS_SOMEIPSD_00020)
Publish/Subscribe Registration/Deregistration behavior is as shown in Figure 4.22 c

sd SEQ-Registration-Deregistration
Client 1 Server Client 2
OfferService() OfferService()
SubscribeEventgroup()
updateRegistration()
SubscribeEventgroupAck + Events()
Event()
Event() Event()
Event() Event()
StopSubscribeEventgroup()
Event()
Figure 4.22: Publish/Subscribe Registration/Deregistration behavior (figure ignoring

timings)
[PRS_SOMEIPSD_00454] d The SOME/IP-SD on the server shall delete the subscrip-

tion, if a relevant SOME/IP error occurs after sending an event or notification event. c
The error includes but is not limited to not being able to reach the communication
partner and errors of the TCP connection.
Publish/Subscribe with link loss at server is as shown in Figure 4.23 c

sd SEQ-LinkLossServ er
Server Client
No registration. OfferService()
linkDown()
deleteRegistrations()
linkUp()
OfferService() [Session ID=1, Reboot=1]

Reboot
detected!
Figure 4.23: Publish/Subscribe with link loss at server (figure ignoring timings)
[PRS_SOMEIPSD_00461] d The client shall open a TCP connection to the server

before sending the Subscribe Eventgroup entry if the Service is offered over TCP
and the client requests an Eventgroup over TCP according to the configuration. c
(RS_SOMEIPSD_00015)
[PRS_SOMEIPSD_00462] d After a client has sent a Subscribe Eventgroup entry the
server shall send a Subscribe Eventgroup Ack entry. c(RS_SOMEIPSD_00015)
[PRS_SOMEIPSD_00463] d The client shall wait for the Subscribe Eventgroup Ack
entry acknowledging a Subscribe Eventgroup entry. If this Subscribe Eventgroup Ack
entry does not arrive before the next Subscribe Eventgroup entry is sent, the client
shall do the following:
• If the "Explicit Initial Data Control Flag of the Server is set to 0, send a Stop Sub-
scribe Eventgroup entry and a Subscribe Eventgroup entry in the same SOME/IP-
SD message the Subscribe Eventgroup entry would have been sent with.

• If the "Explicit Initial Data Control Flag of the Server is set to 1, set the Initial Data
Requested Flag of the next Subscribe Eventgroup Entry to 1.
c(RS_SOMEIPSD_00015) Note:
This behavior exists to cope with short durations of communication loss, so new Initial
Events are triggered to lower the effects of the loss of messages.
[PRS_SOMEIPSD_00577] d The requirement [PRS_SOMEIPSD_00463] shall not be
applied to Offer Service entries that are a reaction to Find Service entries. This means
that the Subscribe Eventgroup Ack entry of a Subscribe Eventgroup entry that was
triggered by a unicast Offer Service entry is not monitored as well as upon a unicast
Offer Service entry the Stop Subscribe Eventgroup entry/Subscribe Eventgroup entry
is not sent. c(RS_SOMEIPSD_00015)
Rationale:
If a client sends a Subscribe Eventgroup entry as a reaction to a unicast offer, and a
multicast offer arrives immediately after that but before the the Subscribe Eventgroup
Ack entry could be sent by the server and received, the client shall not complain (i.e.
Stop Subscribe/Subscribe) about a not yet received acknowledgement.
Note:
This behavior exists to cope with short durations of communication loss. The receiver
of a Stop Subscribe Eventgroup and Subscribe Eventgroup combination would sent
out Initial Events to lower the effects of the loss of messages.
[PRS_SOMEIPSD_00464] d If the initial value is of concern - i.e. for fields - and the
client has the Explicit Initial Data Control Flag (in the SOME/IP-SD header) set to 0,
the server shall send the first notifications/events (i.e. initial events) immediately after
sending the Subscribe Eventgroup Ack. c(RS_SOMEIPSD_00015)
[PRS_SOMEIPSD_00822] d If the server receives a Subscribe Eventgroup entry with
the Explicit Initial Data Control Flag (in the SOME/IP-SD header) set to 1, the server
shall send notifications/events (i.e. initial events) immediately after sending the Sub-
scribe Eventgroup Ack. c(RS_SOMEIPSD_00015)
[PRS_SOMEIPSD_00823] d The client shall repeat the Subscribe Eventgroup entry, if
it did not receive the notifications/events in a configurable timeout independent of the
setting of the Explicit Initial Data Control Flag. c(RS_SOMEIPSD_00015)
[PRS_SOMEIPSD_00465] d It is not allowed to send initial values of events upon sub-
scriptions (pure event and not field). c(RS_SOMEIPSD_00015)
[PRS_SOMEIPSD_00120] d The event messages of field notifiers shall be sent on
subscriptions (field and not pure event). c(RS_SOMEIPSD_00015)
[PRS_SOMEIPSD_00121] d If a subscription was already valid and is updated by a
Subscribe Eventgroup entry, no initial events shall be sent. c(RS_SOMEIPSD_00015)
[PRS_SOMEIPSD_00122] d Receiving Stop Subscribe / Subscribe combinations trig-
ger initial events of field notifiers. c(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00123] d The initial events shall be sent after the Subscribe Event-
group Ack. c(RS_SOMEIPSD_00015)
Publish/Subscribe State Diagram (server behavior for unicast eventgroups) is
as shown in Figure 4.24 c(RS_SOMEIPSD_00015, RS_SOMEIPSD_00016)
stm Serv ice Discov ery Ev entgroup Pub/Sub (Unicast)
Ev entgroup_PubSub (Unicast Ev entgroup)

Initial
Serv ice Down ServiceUp
[Service==Down] OfferService is implicit
ServiceDown PublishEventgroup
[Service==Up]
Serv ice Up
Initial Not Subscribed Subscribed

receive(SubscribeEventgroup)
/enableEvents()
send(SubscribeEventgroupAck)
/send(SubscribeEventgroupAck)
receive(StopSubscribeEventgroup)
/disableEvents()
TTL_expired [SubscriptionCounter==1]
/disableEvents()
AUTOSAR:
• enableEvents = enableT xRoutingGroup
• disableEvents = disableT xRoutingGroup
Figure 4.24: Publish/Subscribe State Diagram (server behavior for unicast eventgroups)
[PRS_SOMEIPSD_00571] d If a client subscribes to different eventgroups of the same

Service Instance that all include the same field in different SOME/IP-SD messages, the
Server shall send out the initial events for this field for every subscription separately. c
(RS_SOMEIPSD_00015)
[PRS_SOMEIPSD_00572] d If a client subscribes to different eventgroups of the same
Service Instance that all include the same field in the same SOME/IP-SD message,
the Server may choose to not send out the initial event for this field more than once. c
(RS_SOMEIPSD_00015)
Note:
This means the Server can optimize by sending the initial events only once, if supported
by its architecture.

Publish/Subscribe State Diagram (server behavior for multicast eventgroups)

is as shown in Figure 4.25 c(RS_SOMEIPSD_00015, RS_SOMEIPSD_00016)
stm Serv ice Discov ery Ev entgroup Pub/Sub (Multicast)
Ev entgroup_PubSub (Multicast Ev entgroup)

Initial
Serv ice Down ServiceUp
[Service==Down] OfferService is implicit
ServiceDown PublishEventgroup
[Service==Up]
Serv ice Up
Initial
Not Subscribed receive(SubscribeEventgroup) Subscribed
/enableEvents()
SubscriptionCounter++
/SubscriptionCounter++
receive(StopSubscribeEventgroup) [SubscriptionCounter==1]
/SubscriptionCounter--
disableEvents()
receive(StopSubscribeEventgroup) [SubscriptionCounter>1]
TT L_expired [SubscriptionCounter==1]
disableEvents()
TT L_expired [SubscriptionCounter>1]
AUTOSAR:
• enableEvents = enableT xRoutingGroup
• disableEvents = disableTxRoutingGroup
Figure 4.25: Publish/Subscribe State Diagram (server behavior for multicast event-
groups)

Publish/Subscribe State Diagram (server behavior for adaptive unicast/multicast event-

groups) is as shown in Figure 4.26 c(RS_SOMEIPSD_00015, RS_SOMEIPSD_00016)
stm Serv ice Discov ery Ev entgroup Pub/Sub (Unicast to Multicast)
Ev entgroup_PubSub (Unicast-to-Multicast Ev entgroup)
Initial
Serv ice Dow n
[Service==Down] ServiceUp
ServiceDown
[Service==Up]
Initial
Subscribed
receive(SubscribeEventgroup) (Unicast)
[UnicastLimit>SubscriptionCounter]
[UnicastLimit>0] /SubscriptionCounter++
/enableEvents() send(SubscribeEventgroupAck)
Not Subscribed SubscriptionCounter++
receive(StopSubscribeEventgroup)
[SubscriptionCounter==1]
disableEvents()
TTL_expired
[SubscriptionCounter==1]
/SubscriptionCounter-- receive(StopSubscribeEventgroup)
TTL_expired disableEvents() [SubscriptionCounter>1]
[SubscriptionCounter==1 && /SubscriptionCounter--
UnicastLimit==0]
disableMulticastEvents() receive(SubscribeEventgroup)
[UnicastLimit==0] TT L_expired
/enableMulticastEvents() [SubscriptionCounter>1]
SubscriptionCounter++ /SubscriptionCounter--
receive(StopSubscribeEventgroup) send(SubscribeEventgroupAck)
[SubscriptionCounter==1 &&
UnicastLimit==0]
disableMulticastEvents()
Subscribed (Multicast) [SubscriptionCounter>=UnicastLimit]
receive(SubscribeEventgroup) /SubscriptionCounter++
/SubscriptionCounter++ send(SubscribeEventgroupAck)
switchToMulticastEvents()
receive(StopSubscribeEventgroup) receive(StopSubscribeEventgroup)
[SubscriptionCounter>UnicastLimit+1] [SubscriptionCounter==UnicastLimit+1]
/SubscriptionCounter-- /switchToUnicastEvents()
SubscriptionCounter--
TT L_expired
TTL_expired
[SubscriptionCounter>UnicastLimit+1]
[SubscriptionCounter==UnicastLimit+1]
/switchToUnicastEvents()
SubscriptionCounter--
Receiving SubscribeEventgroup triggers sendInitialEvents AUTOSAR:

• enableEvents = enableTxRoutingGroup
• disableEvents = disableTxRoutingGroup
Figure 4.26: Publish/Subscribe State Diagram (server behavior for adaptive unicast/mul-
ticast eventgroups)
[PRS_SOMEIPSD_00134] d SOME/IP-SD shall support automated switching from uni-

cast to multicast if a configured threshold of the numbers of subscribers was reached.
[PRS_SOMEIPSD_00470] d SOME/IP SD Protocol shall support implicit configura-
tion of communication endpoints and registrations of subscribers. These shall be

based on static configurations and not use any SD messages on the network. c
Note:
Depending on the project the use case can exist to use services based on a static
configuration where no Service Discovery takes place on the network at all. In such
cases of implicit registrations, there are no find or subscribe messages exchanged
but the services can be used out of the box. Such preconfigurations are not part of
SOME/IP or SOME/IP SD. Hence, their configuration and implementation is project
specific.
[PRS_SOMEIPSD_00472] d The following entries shall be transported by unicast only:
• Subscribe Eventgroup
• Stop Subscribe Eventgroup
• Subscribe Eventgroup Ack
• Subscribe Eventgroup Nack
4.1.7 Reserved and special identifiers for SOME/IP and SOME/IP-SD.
In this chapter an overview of reserved and special identifiers are shown.

[PRS_SOMEIPSD_00515] d Reserved and special Service-IDs: Table 4.2 c
(RS_SOMEIPSD_00025)
Service-ID Description
0x0000 Reserved
0xFF00 - 0xFF1F Reserved for Testing at OEM
0xFF20 - 0xFF3F Reserved for Testing at Tier-1
0xFF40 - 0xFF5F 0xFF5F Reserved for ECU Internal Communication (Tier-1 proprietary)
0xFFFE Reserved for announcing non-SOME/IP service instances.
0xFFFF SOME/IP and SOME/IP-SD special service (Magic Cookie, SOME/IP-
SD, ...).
Table 4.2: Reserved and Special Service-IDs
[PRS_SOMEIPSD_00516] d Reserved and special Instance-IDs: Table 4.3 c

(RS_SOMEIPSD_00025)
Instance-ID Description
0x0000 Reserved
0xFFFF All Instances
Table 4.3: Reserved and Special Instance-IDs

[PRS_SOMEIPSD_00517] d Reserved and special Method-IDs/Event-IDs: Table 4.4 c

(RS_SOMEIPSD_00025)
Method-ID Description
0x0000 Reserved
0x7FFF Reserved
0x8000 Reserved
0xFFFF Reserved
Table 4.4: Reserved and Special Method/Event-IDs
[PRS_SOMEIPSD_00531] d Reserved eventgroup-IDs: Table 4.5 c

(RS_SOMEIPSD_00025)
Eventgroup-ID Description
0x0000 Reserved
0xFFFF All Eventgroups
Table 4.5: Reserved Eventgroup-IDs
[PRS_SOMEIPSD_00519] d Method-IDs and Event-IDs of Service 0xFFFF: Table 4.6

Method-ID/Event- Description
ID
0x0000 SOME/IP Magic Cookie Messages
0x8000 SOME/IP Magic Cookie Messages
0x8100 SOME/IP-SD messages (events)
Table 4.6: Method-IDs and Event-IDs of Service 0xFFFF
[PRS_SOMEIPSD_00520] d Besides "otherserv" other names are supported by the

configuration option. The following list gives an overview of the reserved names: Ta-
ble 4.7 c(RS_SOMEIPSD_00025)
Name Description
hostname Used to name a host or ECU.
instancename Used to name an instance of a service.
servicename Used to name a service.
otherserv Used for non-SOME/IP Services.
Table 4.7: Reserved Names

5 Configuration Parameters
The Following chapter summarizes all the configuration parameters that are used.
Name Description
INITIAL_DELAY_MIN Minimum duration to delay randomly the transmission of
a message.
INITIAL_DELAY_MAX Maximum duration to delay randomly the transmission of
a message.
REPETITIONS_BASE_DELAY Duration of delay for repetitions.
REPETITIONS_MAX Configuration for the maximum number of repetitions.
REQUEST_RESPONSE_DELAY The Service Discovery shall delay answers using this
configuration item.
CYCLIC_OFFER_DELAY Interval between cyclic offers in the main phase.
SD_PORT is a UDP Port for SD Messages (30490 as default).
SD_MULTICAST_IP address which shall be used by the SD multicast mes-
sages.
Table 5.1: Configuration Parameters

6 Protocol Usage
6.1 Security Considerations for SOME/IP-SD Options

[PRS_SOMEIPSD_00656] d Received SOME/IP-SD messages shall be checked that
the IP Addresses received in Endpoint options and SD Endpoint options are topolog-
ical correct (reference IP Addresses in the IP subnet for which SOME/IP-SD is used)
and shall ignore IP Addresses that are not topological correct as well as the entries
referencing those options. c(RS_SOMEIPSD_00025)
Note:
This means that only Clients and Servers in the same subset are accesible.
6.2 Mandatory Feature Set and Basic Behavior

In this section the mandatory feature set of the Service Discovery and the relevant
configuration constraints are discussed. This allow for bare minimum implementations
without optional or informational features that might not be required for current use
cases.
The following information is defined as compliance check list(s). If a feature is not
implemented, the implementation is considered not to comply to SOME/IP-SDs basic
feature set.
[PRS_SOMEIPSD_00496] d The following entry types shall be implemented:
• Find Service
• Offer Service
• Stop Offer Service
• Subscribe Eventgroup
• Stop Subscribe Eventgroup
• Subscribe Eventgroup Ack
• Subscribe Eventgroup Nack
[PRS_SOMEIPSD_00497] d The following option types shall be implemented, when
IPv4 is required:
• IPv4 Endpoint Option
• IPv4 Multicast Option
• Configuration Option

• IPv4 SD Endpoint Option (receiving at least)

[PRS_SOMEIPSD_00498] d The following option types shall be implemented, if IPv6
is required:
• IPv6 Endpoint Option
• IPv6 Multicast Option
• Configuration Option
• IPv6 SD Endpoint Option (receiving at least)
[PRS_SOMEIPSD_00500] d The following behaviors/reactions shall be implemented
on the Server side:
• The Server shall offer services including the Initial Wait Phase, the Repetition
Phase, and the Main Phase depending on the configuration.
• The Server shall offer services using Multicast (Repetition Phase and Main
Phase) on the multicast address defined by SD_MULTICAST_IP.
• The Server does not need to answer a Find Service in the Repetition Phase.
• The Server shall answer a Find Service in the Main Phase with an Offer Service
using Unicast (no optimization based on unicast flag).
• The Server shall send a Stop Offer Service when shutting down.
• The Server shall receive a Subscribe Eventgroup as well as a Stop Subscribe
Eventgroup and react according to this specification.
• The Server shall send a Subscribe Eventgroup Ack and Subscribe Eventgroup
Nack using unicast.
• The Server shall support controlling the sending (i.e. fan out) of SOME/IP event
messages based on the subscriptions of SOME/IP-SD. This might include send-
ing events based on Multicast.
• The Server shall support the triggering of initial SOME/IP event messages.
RS_SOMEIPSD_00015, RS_SOMEIPSD_00017, RS_SOMEIPSD_00025,
RS_SOMEIPSD_00007)
[PRS_SOMEIPSD_00501] d The following behaviors/reactions shall be implemented
on the Client side:
• The Client shall find services using a Find Service entry and Multicast (on the
multicast address defined by SD_MULTICAST_IP) only in the repetition phase.
• The Client shall stop finding a service if the regular Offer Service arrives.

• The Client shall react to the Servers Offer Service with a unicast SD message
that includes all Subscribe Eventgroups of the services offered in the message of
the Server that the client currently wants to subscribe to.
• The Client shall interpret and react to the Subscribe Eventgroup Ack and Sub-
scribe Eventgroup Nack as specified in this document.
RS_SOMEIPSD_00007)
[PRS_SOMEIPSD_00502] d The following behavior and configuration constraints shall
be supported by the Client:
• The Client shall be able handle Eventgroups if only the TTL of the SD Timings
is specified. This means that of all the timings for the Initial Wait Phase, the
Repetition Phase, and the Main Phase only TTL is configured. This means the
client shall only react on the Offer Service by the Server.
• The Client shall answer to an Offer Service with a Subscribe Eventgroup even
without configuration of the Request-Response-Delay, meaning it should not wait
but answer instantaneously.
RS_SOMEIPSD_00007)
[PRS_SOMEIPSD_00503] d The Client and Server shall implement the Reboot Detec-
tion as specified in this document and react accordingly. This includes but is not limited
to:
• Setting Session ID and Reboot Flag according to this specification.
• Keeping a Session ID counter only used for sending Multicast SD messages.
• Keeping Session ID counters for every Unicast relation for sending Unicast SD
messages.
• Understanding Session ID and Reboot Flag according to this specification.
• Keeping a Multicast Session ID counter per ECU that exchanges Multicast SD
messages with this ECU.
• Keeping a Unicast Session ID counter per ECU that exchanges Unicast SD mes-
sages with this ECU.
• Detecting reboot based on this specification and reaction accordingly.
• Correctly interpreting the IPv4 and IPv6 SD Endpoint Options in regard to Reboot
Detection.
[PRS_SOMEIPSD_00504] d The Client and Server shall implement the "Endpoint Han-
dling for Service and Events". This includes but is not limited to:

• Adding 1 Endpoint Option UDP to an Offer Services if UDP is needed.

• Adding 1 Endpoint Option TCP to an Offer Service if TCP is needed.
• Adding 1 Endpoint Option UDP to Subscribe Eventgroup if events over UDP are
required.
• Adding 1 Endpoint Option TCP to Subscribe Eventgroup if events over TCP are
required.
• Adding 1 Multicast Option UDP to Subscribe Eventgroup Ack if multicast events
are required.
• Understanding and acting according to the Endpoint and Multicast Options trans-
ported as described above.
• Overwriting preconfigured values (e.g. IP Addresses and Ports) with the informa-
tion of these Endpoint and Multicast Options.
• Interpreting incoming IPv4 and IPv6 Endpoint Options as SD endpoints instead
of the Address and Port number in the outer layers.
RS_SOMEIPSD_00007)
[PRS_SOMEIPSD_00821] d The Client and Server shall implement the explicit
requesting of Initial Events. c(RS_SOMEIPSD_00025, RS_SOMEIPSD_00013,
RS_SOMEIPSD_00015, RS_SOMEIPSD_00007)
6.3 Migration and Compatibility
6.3.1 Supporting multiple versions of the same service.
In order to support migrations scenarios ECUs shall support serving as well as using
different incompatible versions of the same service.
[PRS_SOMEIPSD_00512] d In order to support a Service with more than one version
the following is required:
• The server shall offer the service instance of this service once per major version.
• The client shall find the service instances once per supported major version or
shall use the Major Version as 0xFF (all versions).
• The client shall subscribe to events of the service version it needs.
• All SOME/IP-SD entries shall use the same Service-IDs and Instance-IDs but
different Major Versions.

• The server has to demultiplex messages based on the socket they arrive,
Message-ID, Major Versions and relay it based on these conditions internally to
the correct receiver.
RS_SOMEIPSD_00015, RS_SOMEIPSD_00005)

7 References
Bibliography
[1] Glossary
AUTOSAR_TR_Glossary
[2] SOME/IP Protocol Specification
AUTOSAR_PRS_SOMEIPProtocol


AUTOSAR PRS SOMEIPServiceDiscoveryProtocol

Uploaded by

Copyright:

Available Formats

AUTOSAR PRS SOMEIPServiceDiscoveryProtocol

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AUTOSAR PRS SOMEIPServiceDiscoveryProtocol

Uploaded by

Copyright:

Available Formats

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO Release 1.3.0

SOME/IP Service Discovery

Document Status Final

Document Change History

1 of 74 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

2 of 74 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

3 of 74 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

4 of 74 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

1 Introduction and overview

1.1 Protocol purpose and objectives

1.2 Applicability of the protocol

1.2.1 Constraints and assumptions

Currently SOME/IP-SD supports only IP based communication.

1.3.1 Dependencies to other protocol layers

5 of 74 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

Figure 1.1: SOME/IP-SD Dependencies to other protocol layers

6 of 74 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

2.1 Requirements Traceability

Feature Description Satisfied by

7 of 74 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

[RS_SOMEIPSD_00004] SOME/IP Service Discovery Protocol [PRS_SOMEIPSD_00437]

8 of 74 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

9 of 74 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

[RS_SOMEIPSD_00010] SOME/IP Service Discovery Protocol [PRS_SOMEIPSD_00220]

10 of 74 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

[RS_SOMEIPSD_00013] SOME/IP Service Discovery Protocol [PRS_SOMEIPSD_00355]

11 of 74 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

12 of 74 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

[RS_SOMEIPSD_00019] SOME/IP Service Discovery Protocol [PRS_SOMEIPSD_00124]

13 of 74 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

14 of 74 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

3 Acronyms and Abbreviations

Abbreviation / Acronym: Description:

15 of 74 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

Abbreviation / Acronym: Description:

Table 3.1: Acronyms and Abbreviations

16 of 74 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

4.1 SOME/IP Service Discovery (SOME/IP-SD)

4.1.1.1 Terms and Definitions

[PRS_SOMEIPSD_00238] d A separate server service instance shall be used per

4.1.2 SOME/IP-SD Message Format

4.1.2.1 General Requirements

[PRS_SOMEIPSD_00220] d SOME/IP-SD messages shall be sent over UDP. c

17 of 74 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP-SD Header Format is shown in Figure 4.1 c(RS_SOMEIPSD_00001)

Length [32 bit]

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

Flags [8 bit] Reserved [24 bit]

Length of Options Array [32 bit]

Figure 4.1: SOME/IP-SD Header Format

[PRS_SOMEIPSD_00250] d Service Discovery Messages shall start with a SOME/IP

18 of 74 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

[PRS_SOMEIPSD_00158] d The Session-ID (SOME/IP header) shall start with 1 and

19 of 74 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

An example of SOME/IP-SD is as shown below

Figure 4.2: SOME/IP-SD Example PDU

4.1.2.2 SOME/IP-SD Header

[PRS_SOMEIPSD_00252] d SOME/IP-SD shall be transported using SOME/IP as de-