SOME/IP Server Stack

Overview

RAPIDSEA supports SOME/IP protocol as explained in the SOME/IP Protocol page. This page explains the server architecture and details how the user should interface the stack with their custom logic and realize the ECU implementation quickly. It also provides guidelines on adopting the stack for different systems.

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

Application Interface

While the RAPIDSEA SOME/IP server stack can handle most of the functionality such as message validation, service discovery management, subscription handling, Notification process etc, the business logic has to implement the application functionality. the RAPIDSEA SOME/IP server 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_server_get_version_info	To retrieves the major, minor and build version numbers of the SOME/IP server.
rs_some_server_open	To initialize the SOME/IP server instance structure for both discovery and notification process.
rs_some_server_run	To be called to set the run state for state machine for both discovery and notification process.
rs_some_server_sd_service_set_state	To set the service state (online/offline) for the given SOME/IP server service instance.
rs_some_server_set_tx_msg_buf	To set up the transmit buffers to be used for the SOME/IP server communication.
rs_some_server_set_rx_msg_buf	To set up the receive buffers to be used for the SOME/IP server communication.
rs_some_server_req_stop_offer_service	To frame and send the stop offer service
rs_someip_server_set_npdu_info	To Set the NPDU details
rs_some_server_process	To be called to call the discovery and notification’s state machine and process respectively and notification event send function.
rs_some_server_subscribe_init	To initialize the SOME/IP subscription details structure associated with the server
rs_some_server_set_reboot_flag	To be called to set the reboot flag in SOME/IP server instance.
rs_some_server_send_notify_event	To be called to send notification events from server
rs_some_server_sd_rx_msg_handler	To be called to handle the RX SD Message
rs_some_server_close	To free the SOME/IP server handle

There are many functions through which the SOME/IP server 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_server_get_serialized_config_option	called to get the serialized data of configuration option
rcb_some_server_get_load_balancing_option_info	Called to get the data of load balancing option
rcb_some_server_set_deserialize_config_option	Called to set the deserialized data of configuration option
rcb_some_server_rx_resp_err_handler	Called to handle the error response
rcb_some_server_get_mem	Called to get memory
Method setter/getter callbacks	This callbacks must mapped into event information under service details information

SOME/IP Server Configuration Parameter:

Server Configuration

Function	Description
server_addr	SOME/IP Server IP address
sd_unicast_addr	SOME/IP SD Unicast IP address
sd_tx_mode	SOME/IP SD TX Mode unicast/multicast
repetitions_base_delay	SOME/IP SD repetition base delay
repetitions_max	SOME/IP SD repetition max
ip_version	SOME/IP SD IP Version (IPv4/IPv6)
log_level	SOME/IP Server log level
cyclic_offer_delay	SOME/IP SD cyclic offer delay
initial_delay_min	SOME/IP SD initial wait minimum time
initial_delay_max	SOME/IP SD initial wait maximum time
npdu_tx_timeout	SOME/IP NPDU information flag

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

Implementation Guide

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

• Initialize the server 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_server_process functions so that internal timeouts are handled.

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 Server Transmission and Reception Over UDP ( < 1400 bytes)

Transmission:

• For payloads smaller than 1400 bytes, SOME/IP directly uses UDP transport without TP segmentation. The message is wrapped in a SOME/IP header and transmitted in a single frame.

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

Reception:

• When a SOME/IP message under 1400 bytes is received via UDP, it’s directly delivered to the SOME/IP layer for parsing and dispatching to the respective application handler

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

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

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

Transmission:

• For payloads exceeding 1400 bytes, SOME/IP uses SOME/IP-TP over UDP. The TP layer breaks the data into smaller frames and sends them sequentially.

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

Reception:

• Large payloads received over UDP are reassembled by the SOME/IP-TP layer. Segments are combined until a complete message is reconstructed, which is then passed to the application

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

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

SOME/IP Server Transmission and Reception Over TCP

Transmission:

• For reliable, connection-oriented communication, SOME/IP messages are transmitted using TCP. TCP ensures delivery and order, but latency can increase due to retransmissions.

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

Reception:

• SOME/IP over TCP is used when guaranteed message delivery is needed. The TCP stream ensures all bytes arrive in sequence.

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

The below sequence diagram captures the SOMEIP/IP Server 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 Server Stack Buffer Details

The SOME/IP Server stack maintains dedicated buffers and memory structures to manage service discovery, event notifications, and request–response exchanges with multiple clients over TCP and UDP.

Each server instance allocates transmit (TX) and receive (RX) buffers to handle message framing and reassembly. By default, the buffer size is configured to approximately 5 KB, suitable for standard SOME/IP and SOME/IP-TP operations.

In compliance with the AUTOSAR SOME/IP and SOME/IP-TP specifications, the maximum size of a SOME/IP message that fits within a single Ethernet frame is limited by the MTU (≈1400 bytes). When payloads exceed this limit, the stack uses SOME/IP-TP for segmentation and reassembly. Thus, the TP buffer size must always be identical to the SOME/IP buffer size to prevent data loss or truncation during fragmentation or reassembly.

The following summarizes the memory handling modes for the server:

SOME/IP Server Buffer Configuration

Configuration Mode	Description
Without TP (Standard SOME/IP)	Handles single-frame transmissions within Ethernet MTU (≈1400 bytes). Only the SOME/IP layer is active, and TX/RX buffers of 1400 bytes are sufficient.
With TP Enabled (SOME/IP-TP Mode)	Handles multi-frame payloads segmented by SOME/IP-TP. The SOME/IP buffer size and TP buffer size must be equal (e.g., 5 KB) to maintain consistency between segmentation and reassembly logic.

This ensures that both SOME/IP and SOME/IP-TP operate seamlessly during multi-segment message exchanges.

SOME/IP Server Memory Allocation Details

The SOME/IP Server stack uses static and dynamic allocations to manage service information, subscriptions, TCP/UDP sockets, and event notifications. These allocations are configured through compile-time macros defined in rs_someip_server.h.

The following table outlines key structures, macros, and their impact on memory footprint:

SOME/IP Server Static Memory Details

Structure / Field	Macro / Size	Description & Impact
notify_udp_info[RS_SOMEIP_SERVER_MAX_NOTIFY_UDP_SOCKET]	10 (default)	Maintains UDP notification socket information for service event transmission. Each element holds an rs_someip_udp_proto_info_t instance. Increasing this allows more parallel UDP notifications but increases memory.
server_tcp_info[RS_SOMEIP_SERVER_MAX_NOTIFY_TCP_SOCKET]	10 (default)	Holds TCP notification socket instances for event publishing. Each includes socket configuration, handle, and up to five client connections. Memory grows proportionally with socket count.
client_inst[RS_SOMEIP_SERVER_MAX_NUM_OF_TCP_CLIENT_CONN]	5 (default)	Represents active TCP clients connected to the server for SOME/IP notification. Each instance tracks session state and handle. Increasing this improves concurrency but raises static RAM usage.
tx_msg / rx_msg	Structure type: rs_someip_msg_t	Represents SOME/IP message transmit and receive buffers. The payload buffer inside this structure is typically ~5 KB. If TP mode is enabled, TP buffer size must equal SOME/IP buffer size.
ptr_service_info	User Defined Size	Points to service configuration details such as eventgroup lists, port number, and protocol type. Each instance corresponds to one advertised SOME/IP service.
ptr_subscribe_details	User Defined Size	Holds subscription information for connected clients. Each rs_someip_server_subscribe_info_t tracks socket addresses, TTL, and last subscription time.
notify_process_info	Static structure	Encapsulates notification sockets (UDP and TCP) for the server instance. Defined by rs_someip_server_notify_info_t — consumes memory based on configured socket counts.
discov_udp_info	Static structure	Contains Service Discovery (SD) UDP socket information, used to broadcast service availability and respond to find-service requests.
rcb_some_server_get_mem	Size depends on the user	This function is used to get memory for the given user size.

Note

• All macros (e.g., RS_SOMEIP_SERVER_MAX_NOTIFY_UDP_SOCKET) define compile-time constants that directly influence the static memory footprint.

• Increasing these macros enhances scalability (e.g., more clients or notifications) but proportionally increases RAM consumption.

• Reducing any of these may lead to runtime connection limits or dropped event notifications.

• TX/RX buffer sizes in SOME/IP and SOME/IP-TP must always be equal when TP mode is active.

• Ensure total memory usage remains within target MCU or OS resource limits, particularly when enabling multi-client TCP notifications.

See also

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

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

SOME/IP Server Stack Memory Usage

ROM/RAM Consumption (Stack only)

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

ROM/RAM Consumption (Stack + Application)

Platform	Memory	Size
Micro controller (iMXRT)	ROM	79KB
Micro controller (iMXRT)	RAM	137KB

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 interfaces 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 Server Demo.

SOME/IP Server Header Details

Documentation from the relevant header as follows:

Warning

doxygenfile: Cannot find file “rs_someip_server.h