SOME/IP Client Stack

SOME/IP Client Overview

RAPIDSEA supports SOME/IP protocol as explained in the SOME/IP Protocol page. This page describes the client architecture, how the user should interface the stack with their own logic, and how to swiftly implement the tester. It also provides guidelines on adopting the stack for different systems.

The below diagram captures the block level diagram of the SOME/IP client and how it interfaces with other modules.

Application Interface

While the RAPIDSEA SOME/IP client stack can handle most of the functionality such as message validation, service discovery management, subscription handling, Subscriber process etc, the business logic has to implement the application functionality. The RAPIDSEA SOME/IP client clearly defines API and callback functions that are essential for the user to use/implement.

The below table captures the function that are to be called from the application logic.

API Functions

Function	Description
rs_someip_client_get_version_info	To retrieves the major, minor and build version numbers of the SOME/IP client.
rs_some_client_open	To initialize the SOME/IP client instance structure for both discovery and Subscriber process.
rs_some_client_sd_service_set_state	To set the service state (requested/released) for the given SOME/IP client service instance.
rs_some_consumed_eventgroup_set_state	To set the request state (subscribe/unsubscribe) for the given consumed event group of a SOME/IP client service instance.
rs_some_client_subscribe_init	To initialize the SOME/IP subscription details structure associated with the client.
rs_some_client_run	To be called to set the run state for state machine for both discovery and Subscriber process.
rs_some_client_set_rx_msg_buf	To set up the receive buffers to be used for the SOME/IP client communication.
rs_some_client_set_tx_msg_buf	To set up the transmit buffers to be used for the SOME/IP client communication.
rs_some_client_req_find_service	To be called to find the service of given service ID and instance ID.
rs_some_client_send_stop_subscribe_req_all	To frame and send the stop subscribe eventgroup request for all eventgroups and reset the subscription in client side
rs_some_client_sd_rx_msg_handler	To be called to handle the RX SD Message.
rs_some_client_send_req	To be called to send the request for subscribed eventgroups (read/write/method)
rs_some_client_set_reboot_flag	To be called to set the reboot flag in SOME/IP client instance.
rs_some_client_process	To be called to call the discovery and Subscriber’s state machine and process respectively.
rs_someip_client_set_npdu_info	To be called to Set the NPDU details
rs_some_client_close	To freed the SOME/IP client handle.

There are many functions through which the SOME/IP client stack retrieves information from the application logic or indicate actions to be performed. These functions are captured in the below table.

Callback Functions

Function	Description
rcb_some_client_rx_resp_err_handler	Called to indicate reception of error response for any request
rcb_some_client_rx_notify_resp_handler	Called when notification events received from server.
rcb_some_client_subscription_resp_handler	Called when response for a service discovery request is received
rcb_some_client_get_serialized_config_option	Called when function get the serialized data of configuration option
rcb_some_client_set_deserialize_config_option	Called when function set the deserialized data of load balancing option
rcb_some_client_set_load_balancing_option_info	called when function set the data of load balancing option
rcb_some_client_get_mem	Called to get memory
Method setter/getter callbacks	This callbacks must mapped into event information under service details information

SOME/IP Client Configuration Parameter:

Client Configuration

Function	Description
sd_unicast_addr	SD Unicast IP address
client_addr	SOME/IP client IP address
sd_tx_mode	SD TX Mode unicast/multicast
subscriber_port	Subscriber Port number
ip_version	SOME/IP internet protocol version
client_id	SOME/IP Client ID
repetitions_base_delay	SOME/IP SD repetition base delay
repetitions_max	SOME/IP SD repetition max
initial_delay_min	SOME/IP SD initial wait minimum time
initial_delay_max	SOME/IP SD initial wait maximum time
log_level	SOME/IP Client log level
npdu_tx_timeout	SOME/IP NPDU transmit timeout

These functions are documented in detail in the below sections. It is important for the client to implement these functions correct for proper operation of the system.

Implementation Guide

This section explains how the SOME/IP client can be implemented using the RAPIDSEA stack. The stack is available in source form; the steps to be followed are

• Initialize the client configuration

• Implement the Callback functions mentioned above

• Initialize the buffers necessary for the operation

• Initialize the SOME/IP stack function.

• Periodically call the rs_some_client_process functions so that internal timeouts are handled.

• If there is a need to send a request to ECU/server, send via rs_some_client_send_req call

• When the response from server is received, rcb_some_client_rx_resp_handler function called.

• On reception of negative response from server, rcb_some_client_rx_resp_err_handler function is called.

High level flow chart is depicted below:

The below diagram captures the high level sequence of operations associated with the SOME/IP stack.

SOME/IP Client Transmission and Reception Over UDP ( < 1400 bytes)

Transmission:

• When payload < 1400 bytes, the SOME/IP Client sends the message directly over UDP without fragmentation. The below block diagram captures the SOMEIP/IP Server Transmission Over UDP.

The below block diagram captures the SOMEIP/IP Client Transmission Over UDP

Reception:

• For small UDP messages (<1400 bytes), the client directly receives and processes the packet without TP.

The below block diagram captures the SOMEIP/IP Client Reception Over UDP

The below sequence diagram captures the SOMEIP/IP Client Transmission and Reception Over UDP

SOME/IP Client Transmission and Reception Over UDP ( > 1400 bytes)

Transmission:

• For payloads >1400 bytes, the client uses SOME/IP-TP over UDP. Data is segmented into smaller frames, transmitted sequentially, and reassembled at the receiver end.

The below block diagram captures the SOMEIP/IP Client Transmission Over UDP with TP

Reception:

• When receiving data >1400 bytes over UDP, the client uses the SOME/IP-TP module for fragment reassembly. Only after complete message reassembly, the data is passed to the application.

The below block diagram captures the SOMEIP/IP Client Reception Over UDP with TP

The below sequence diagram captures the SOMEIP/IP Client Transmission and Reception Over UDP with TP

SOME/IP Client Transmission and Reception Over TCP

Transmission:

• For reliable, ordered, and connection-oriented transmission, the SOME/IP Client uses TCP

The below block diagram captures the SOMEIP/IP Client Transmission Over TCP

Reception:

• In TCP reception, the client reads a continuous stream of bytes, extracts complete SOME/IP messages, and delivers them to the appropriate service.

The below block diagram captures the SOMEIP/IP Client Reception Over TCP

The below sequence diagram captures the SOMEIP/IP Client Transmission and Reception Over TCP

This can be implemented in a bare-metal system or over RTOS or over full fledged OS such as Linux etc.

SOME/IP Client Stack Buffer Details

The SOME/IP communication stack maintains dedicated transmit (TX) and receive (RX) buffers to manage application data exchanged over Ethernet. By default, each buffer is configured with a size of approximately 5 KB, which is sufficient to handle typical message sizes within the Ethernet frame limits.

In accordance with the AUTOSAR SOME/IP and SOME/IP-TP specifications, a single SOME/IP message should generally not exceed the Ethernet MTU (typically around 1400 bytes). When a message payload exceeds this limit, the SOME/IP layer delegates transmission to the SOME/IP Transport Protocol (SOME/IP-TP). The TP layer is responsible for segmenting the large payload into multiple transport frames for transmission and reassembling them at the receiver side.

Since the SOME/IP layer and the SOME/IP-TP layer operate together for such large messages, the TP buffer size must always be configured equal to the SOME/IP buffer size. This ensures seamless data handover between the two modules and prevents buffer overflow or truncation during segmentation and reassembly.

Hence, the memory allocation strategy for SOME/IP client operation can be summarized as follows:

SOME/IP Client Buffer Configuration

Configuration Mode	Description
Without TP (Standard SOME/IP)	Only the SOME/IP stack is used. TX and RX buffers of around 1400 bytes are sufficient to handle single-frame transmissions within the Ethernet MTU limit.
With TP Enabled (SOME/IP-TP Mode)	Large messages exceeding MTU are transferred via SOME/IP-TP. The SOME/IP buffer size and TP buffer size must be identical (e.g., 5 KB) to ensure proper segmentation and reassembly of large data packets.

This configuration guarantees consistent memory handling between SOME/IP and SOME/IP-TP layers and aligns with AUTOSAR recommendations for transport protocol interoperability.

SOME/IP Client Memory Allocation Details

The SOME/IP Client stack statically allocates multiple buffers and array instances to manage service subscriptions, eventgroup tracking, and protocol communication. Each buffer size directly impacts memory footprint and must remain consistent with the configured maximums in rs_someip_client.h.

The following table summarizes all major memory allocations defined in this module:

SOME/IP Client Static Memory Details

Structure / Field	Macro / Size	Description & Impact
subscriber_udp_info[RS_SOMEIP_CLIENT_MAX_UDP_SOCKET]	20 (default)	Maintains UDP socket information for subscribed services. Each element holds an instance of rs_someip_udp_proto_info_t. Increasing this count allows more concurrent UDP subscriptions but proportionally increases RAM usage.
conn_inst[RS_SOMEIP_CLIENT_MAX_TCP_CONN]	20 (default)	Holds TCP connection information structures for SOME/IP client subscribers. Each instance contains socket configuration, state, and connection handle. Modifying this macro changes the number of parallel TCP sessions supported.
sub_evtgrp_list[RS_SOMEIP_CLIENT_MAX_SUB_EVTGRP_LIST]	25 (default)	Stores the subscribed Eventgroup IDs for each service. Increasing this enables more eventgroups per service but increases static allocation size in rs_someip_client_subscribe_info_t.
tx_msg / rx_msg	Structure type: rs_someip_msg_t	Used as transmission and reception buffers for SOME/IP messages. Their internal payload buffer is defined by the SOME/IP layer (typically ~5 KB). If SOME/IP-TP is enabled, the TP buffer size must match the SOME/IP buffer size to ensure proper segmentation and reassembly.
ptr_service_info	User Defined Size	Points to service information structures allocated during initialization. Each rs_someip_client_service_info_t instance contains eventgroup pointers and service state.
ptr_subscribe_details	User Defined Size	Points to subscription information list; allocated based on configured number of subscribed services.
number_of_services / number_of_subscribe	Integer count	Indicates how many service and subscription instances are active.
rcb_some_client_get_mem	Size depends on the user	This function is used to get memory for the given user size.

Note

• All array sizes defined by macros (e.g., RS_SOMEIP_CLIENT_MAX_TCP_CONN) are compile-time constants.Changing these will alter the static memory footprint of the client instance.

• The SOME/IP and SOME/IP-TP buffer sizes must remain equal when TP mode is used, to ensure buffer alignment during message fragmentation and reassembly.

• Increasing any of these macros will directly increase the RAM usage of the SOME/IP client instance.Always verify memory availability and heap/stack limits in the target environment.

• Reducing array sizes may cause runtime errors if more services or eventgroups are subscribed than allowed.

See also

• All the rs_some_client_xx calls are must be called in a single thread.

• For reference, see the apps/someip_client_demo under RS source directory page

SOME/IP Client Stack Memory Usage

ROM/RAM Consumption (Stack only)

Platform	Memory	Size
Micro controller (iMXRT)	ROM	46KB
Micro controller (iMXRT)	RAM	1KB

ROM/RAM Consumption (Stack + Application)

Platform	Memory	Size
Micro controller (iMXRT)	ROM	81KB
Micro controller (iMXRT)	RAM	143KB

Note:

The above table captures the memory usage for five services. Each service has two or one event groups, and across these eventgroups, a total of ten events are mapped. If you add or remove services, the memory usage will increase or decrease accordingly.

Dependency

This stack depends on the below RAPIDSEA interface that can be obtained or custom implemented.

1. SOME/IP Transport Protocol

2. Socket Interface

3. SOME/IP Service Discovery

4. SOME/IP Transformer

Example demo

An example implementation is available along with the release and is described in SOME/IP Client Demo.

SOME/IP Client Header

Documentation from the relevant header as follows:

Warning

doxygenfile: Cannot find file “rs_someip_client.h