watonomous.github.io
[ Electrical Division : SOME/IP Understanding ]
Created by [ Rowan Dempster] on Dec 27, 2019
Understanding the SOME/IP Protocol:
(Scalable service-Oriented MiddlewarE over IP)
Better formatted document with images at the [following link:]{.inline-comment-marker data-ref=”77955edf-76aa-4a40-abda-3e94b1a69dbb”}
https://docs.google.com/document/d/1vu85K_rU_VYzeU9Eh6J0bTMCMswPzM1OY7El1kgjgWc/edit
SOME/IP is an automotive/embedded communication protocol which supports
remote procedure calls, event notifications and the underlying
serialization/wire format.
Compatible with AUTOSAR
Service-oriented communication over a network. Based on service
definitions that list the functionality of the service. Service can hold
combination of zero or multiple events, methods, or fields.
Fields (one or more of the following 3):
Notifier which sends data on change from provider to subscribers
Getter which can be called by subscriber to query the provider for a
value
Setter which can be called by subscriber when it wants to change value
on provider side
Difference Between Notifier of Field and Event: events only sent on
change, notifier of field sends data directly after subscription.
Serialization: → represented in Protocol Data Units (PDUs) as a payload
of either UDP or TCP messages, transported over IP-based network.
Header (in order):
Message ID (Service ID/ Method ID): 32 bits
Used to identify RPC call to a method of an application or to identify
an event.
Assignment of ID is up to the user
Similar to CAN ID
Length: 32 bits
Contains length in bytes starting from Request ID/Client ID until the
end of the SOME/IP message
Request ID (Client ID / Session ID): 32 bits
Allows provider and subscriber to differentiate multiple parallel uses
of the same method, event, getter or setter.
Client ID: 16 bits, Session ID: 16 bits
Protocol Version: 8 bits
Interface Version: 8 bits
Message Type: 8 bits
Differentiates different types of messages:
In Table at bottom.
Return Code: 8 bit
Signals if request was successfully processed.
Payload: (Variable Size)
Size depends on transport protocol used
UDP: 0-1400 bytes (limitation of 1400 for future changes to protocol)
Consists of data elements for events or parameters for methods
Event, Field and Eventgroup
Eventgroup: Logical grouping of events and notification events of fields
inside of a service in order to allow subscription.
Events and notifications are transported using RPC.
Events are structured like → Service ID: 16 bit | 1 [1 bit] | Event
ID: last 15 bit
Endianness:
SOME/IP Header: Big Endian
Parameters inside payload: defined by configuration
Serialization of Data Structures
Based on parameter list defined by the interface specification.
Interface specification defined exact position of all data structure in
the PDU. Alignment is used to align the beginning of data inserting
padding elements after the data to ensure that the aligned data starts
at a certain memory address. Alignment is calculated from start of
SOME/IP message. No padding behind fixed length data elements to ensure
data alignment. Alignment of data behind variable length data elements
is a multiple of 8, 16 or 32 bits.
Supports data structures shown in table at bottom. Byte order is
specified for each parameter by configuration. For boolean, lowest bit
of uint8 is interpreted and rest is ignored.
Structs:
Memory Alignment of serialization outlined in Table below
Length field of struct describes # of bytes struct occupies for SOME/IP
transport.
Length > Struct Length
Length < Sum of all Struct Members
Length field of struct describes # of bytes struct occupies for SOME/IP
transport.
Serialization of structs follows DFT (depth-first traversal).
Strings:
UTF-8, UTF-16BE, UTF-1LE encodings supported
UTF-16BE, UTF-1LE null terminated (end with 0x00 bytes)
All strings start with Byte Order Mark (BOM), allows possibility of
detecting type of encoding
Arrays:
1D array with fixed length N carries N elements of the same type
Multidimensional arrays follow in-memory layout (row-major order) →
visual seen in figure below
Dynamic length arrays
Optional length field at beginning of an array should be used to specify
length in Bytes
of static length elements → n [bytes] / e [element size]
Supports different length for columns and different lengths for rows in
the same dimension → Note: length indicator needs to be present in front
of every dynamic length array.
Enums:
Not considered, transmitted as uint types
Bitfields:
Transported as uint types
Union/Variant
Use multiple data types in the same memory
Datatype used is decided during execution
Consists of Length Field [32 bit], Type Field [32 bit], Data
including padding [sizeof(padding) = length - sizeof(data)]
Padding occupies unused data depending on type chosen
Specification of Protocol
UDP Binding
Header format allows transporting more than one SOME/IP message in a
single UDP packet. The SOME/IP implementation shall identify the end of
a SOME/IP message by means of the SOME/IP length field. Based on the UDP
length field, it is determined if there are additional SOME/IP
messages.
TCP Binding
SOME-IP-TP-Header
Has a TP header right after the SOME/IP header and before SOME/IP
payload, with structure seen in Figure below.
Example:
Comments:
+———————————————————————–+
| [] |
| |
| Is this page still used or not? |
| |
| {.smallfont align=”left” style=”color: #666666; width: 98%; margi |
| n-bottom: 10px;”} |
| 
|
| Posted by qf2yan at Apr 24, 2020 17:04 |
| |
+———————————————————————–+
Document generated by Confluence on Nov 28, 2021 22:40