feat: Integrate opensomeip with Eclipse OpenBSW

[vtz]

Summary

Integrate the opensomeip SOME/IP protocol stack into Eclipse OpenBSW, enabling SOME/IP communication (serialization, transport, Service Discovery, RPC, events, E2E) within OpenBSW-based automotive embedded applications.

Motivation

OpenBSW is an open-source automotive BSW framework with lifecycle management, CAN/Ethernet networking, UDS diagnostics, and a reference application for NXP S32K148 and POSIX platforms. It currently supports basic TCP/UDP via its cpp2ethernet / lwipSocket modules but has no SOME/IP protocol support.

Adding SOME/IP to OpenBSW would:

• Enable service-oriented communication (SOA) in OpenBSW-based ECUs
• Allow SOME/IP Service Discovery for dynamic service registration
• Provide AUTOSAR-compatible SOME/IP serialization and E2E protection
• Complement OpenBSW's existing DoIP/UDS diagnostics with SOME/IP transport

Technical Gap Analysis

OpenBSW and opensomeip have significant architectural differences that must be bridged:

Aspect	opensomeip	OpenBSW	Gap
C++ standard	C++17	C++14	Must resolve C++17 dependencies (see #171)
Threading	platform::Mutex, platform::Thread, platform::ConditionVariable	async::execute/schedule, FreeRtosAdapter, async::Lock (interrupt-based)	Different concurrency model — opensomeip uses thread+mutex, OpenBSW uses async task dispatch
Networking	BSD socket API (socket, bind, sendto, poll) via net_impl.h	udp::AbstractDatagramSocket, tcp::AbstractSocket with IDataListener callbacks	Fundamentally different I/O model — sync BSD vs. async OOP (see #172)
Memory	std::vector, std::unordered_map, std::shared_ptr, heap allocation	ETL containers (etl::array, etl::span, etl::delegate), static allocation	opensomeip uses heap extensively (see #174)
Containers	STL (std::vector, std::string, std::unordered_map, std::function)	ETL (etl::array, etl::span, etl::string, etl::delegate)	No ETL usage in opensomeip currently
Build	CMake with FetchContent, C++17 required	CMake with add_subdirectory, C++14, cross-compilation for S32K148	Build integration needed

Integration Strategy

Phased Approach

The integration depends on the outcomes of prerequisite investigation tickets. Three integration strategies are possible, ordered by increasing architectural alignment:

Phase 0: Prerequisites (parallel investigations)

• Investigate C++17 dependencies that would break C++14 compatibility #171 — C++17 compatibility: determine if opensomeip can compile under C++14 (or dual-standard)
• Investigate reducing heap/STL usage in favor of ETL-compatible patterns #174 — STL/heap reduction: determine if ETL-compatible patterns can replace heap-allocating containers
• feat: Event-driven transport interface for async I/O integration #172 — Event-driven transport: design callback-based transport interface

Phase 1: Quick Integration (bypass OpenBSW abstractions)

Use opensomeip's existing FreeRTOS + lwIP backends directly, bypassing OpenBSW's async and cpp2ethernet layers:

OpenBSW Lifecycle → initializes opensomeip
opensomeip → FreeRTOS tasks + lwIP sockets (directly)
OpenBSW → cpp2ethernet + lwipSocket (separately)

• Pros: No opensomeip changes needed (if C++17 issue is resolved). Quickest path.
• Cons: Two networking paths coexist. Breaks OpenBSW's layered architecture. opensomeip threads are invisible to OpenBSW's async framework.
• Where: OpenBSW repo — new libs/bsw/someip/ module wrapping opensomeip

Phase 2: Native Integration (use OpenBSW's abstractions)

After #172 (event-driven transport) is complete:

OpenBSW Lifecycle → initializes opensomeip
opensomeip EventDrivenUdpTransport → OpenBSW AbstractDatagramSocket → lwIP
opensomeip EventDrivenTcpTransport → OpenBSW AbstractSocket → lwIP
opensomeip async → OpenBSW async::execute/schedule

• Pros: Single networking path. Respects OpenBSW's architecture. opensomeip tasks visible to OpenBSW scheduler.
• Cons: Requires feat: Event-driven transport interface for async I/O integration #172 and potentially a new threading PAL backend (include/platform/openbsw/)
• Where: Adapter module in OpenBSW + potential PAL backend in opensomeip

Phase 3: Deep Integration (ETL + C++14)

After #171 and #174 are resolved:

• opensomeip compiles under C++14
• opensomeip uses ETL-compatible containers (or ETL directly)
• No STL/heap conflicts with OpenBSW code
• Full architectural alignment

Where the Code Lives

Following the split approach established for other platform ports:

Component	Repository	Rationale
PAL backend (if needed): include/platform/openbsw/	opensomeip	Consistent with FreeRTOS/ThreadX/Zephyr backends; evolves with PAL contract
Event-driven transport interfaces	opensomeip	Part of #172; general-purpose, not OpenBSW-specific
OpenBSW adapter module	OpenBSW	Implements IUdpSocketAdapter using OpenBSW's AbstractDatagramSocket; wires lifecycle
OpenBSW SOME/IP service examples	OpenBSW	Application-level code

OpenBSW Module Structure (proposed)

libs/bsw/someip/
├── CMakeLists.txt              # Pulls opensomeip, configures flags
├── include/
│   └── someip/
│       ├── SomeIpModule.h      # OpenBSW lifecycle integration
│       ├── SomeIpUdpAdapter.h  # IUdpSocketAdapter → AbstractDatagramSocket
│       └── SomeIpTcpAdapter.h  # ITcpSocketAdapter → AbstractSocket
├── src/
│   ├── SomeIpModule.cpp
│   ├── SomeIpUdpAdapter.cpp
│   └── SomeIpTcpAdapter.cpp
└── doc/
    └── index.rst

Tasks

• Complete prerequisite investigations (Investigate C++17 dependencies that would break C++14 compatibility #171, feat: Event-driven transport interface for async I/O integration #172, Investigate reducing heap/STL usage in favor of ETL-compatible patterns #174)
• Based on Investigate C++17 dependencies that would break C++14 compatibility #171 results: resolve C++17 build compatibility with OpenBSW's toolchain
• Implement Phase 1 (quick integration) as proof of concept
• Design OpenBSW lifecycle integration (SomeIpModule init/shutdown within OpenBSW's lifecycle manager)
• Implement Phase 2 adapter (after feat: Event-driven transport interface for async I/O integration #172 provides event-driven transport)
• Test on POSIX platform first (OpenBSW supports POSIX builds)
• Test on S32K148 target (OpenBSW's primary embedded target)
• Document integration guide

Acceptance Criteria

• opensomeip SOME/IP stack runs within an OpenBSW application
• SOME/IP UDP transport works via OpenBSW's networking layer
• Service Discovery operates for service registration and discovery
• Integration follows OpenBSW's module conventions (lifecycle, logging, build)
• Works on both POSIX and S32K148 platforms
• No regressions in standalone opensomeip tests

Dependencies

• Investigate C++17 dependencies that would break C++14 compatibility #171 — C++17 vs C++14 compatibility investigation
• feat: Event-driven transport interface for async I/O integration #172 — Event-driven transport interface
• Investigate reducing heap/STL usage in favor of ETL-compatible patterns #174 — STL/heap reduction investigation

References

• Eclipse OpenBSW repository
• OpenBSW documentation
• opensomeip platform abstraction layer: include/platform/{posix,freertos,threadx,zephyr,lwip}/
• opensomeip integration guide: docs/INTEGRATION_GUIDE.md