Compatibility and Migration Requirements¶
This section defines Software Low-Level Requirements (SW-LLR) for SOME/IP forward compatibility, multi-version service support, and reserved identifier handling.
Forward Compatibility¶
The software shall support receiving messages with unknown or trailing extensible payload fields that are longer than expected by ignoring the trailing bytes without error. The software shall strictly validate header and overall message length consistency and reject messages whose header length does not match the actual data length. Rationale: Forward compatibility enables incremental service updates without breaking existing clients; strict header-length validation prevents corrupt or truncated frames from being processed. Code Location: |
The software shall support default values for parameters that are missing from received messages to enable forward compatibility with newer interface versions. Rationale: Default values prevent deserialization failures when communicating with newer interface versions. Code Location: |
The software shall support receiving and silently dropping unknown SOME/IP messages. Rationale: Silently dropping unknown messages prevents error cascades in mixed-version deployments. Code Location: |
The software shall allow every client to access every configured Service Instance and Eventgroup on the port. Rationale: Open access simplifies deployment and avoids unnecessary access control complexity at the SOME/IP layer. Code Location: |
FindService entries shall set Minor Version to 0xFFFFFFFF (ANY) to support forward compatibility. ECUs shall subscribe to Eventgroups independently of Minor Version. Rationale: Wildcard minor version in FindService enables clients to discover any compatible service regardless of minor version differences. Code Location: |
Multi-Version Service Support¶
The software shall support serving different incompatible versions of the same service. The server shall offer each major version separately and demultiplex messages by socket, Message ID, and Major Version. Rationale: Multi-version hosting enables gradual migration of clients to new service interfaces. Code Location: |
The client shall find service instances per supported major version (or use 0xFF for any). All SD entries shall use the same Service ID and Instance ID but different Major Versions. Clients shall subscribe to events of the service version they need. Rationale: Per-version discovery allows clients to use only the service version they understand. Code Location: |
Reserved Identifier Handling¶
The software shall handle reserved and special Service IDs per the specification: 0x0000 (reserved), 0x0101 (diagnostics), 0x433F (reserved), 0xFFFE (non-SOME/IP), 0xFFFF (SOME/IP-SD). Rationale: Correct reserved Service ID handling prevents conflicts with system services and SD. Code Location: |
The software shall handle reserved and special Instance IDs: 0x0000 (reserved), 0xFFFF (all instances / wildcard). Rationale: Reserved Instance IDs (0x0000 and 0xFFFF) have special semantics that must be enforced. Code Location: |
The software shall handle reserved and special Method IDs and Event IDs: 0x0000 (reserved for methods), 0x7FFF (reserved), 0x8000 (reserved for events), 0xFFFF (reserved). Rationale: Method and Event ID boundaries define the method/event namespace separation. Code Location: |
The software shall handle reserved and special Eventgroup IDs: 0x0000 (reserved), 0xFFFF (all eventgroups / wildcard). Rationale: Reserved Eventgroup IDs prevent subscription conflicts. Code Location: |
The software shall handle Method IDs for Service 0xFFFF: 0x0000 (reserved), 0x8000 (reserved), 0x8100 (SOME/IP-SD). Rationale: SD-specific Method IDs ensure correct SD message routing. Code Location: |
Compatibility Informational¶
The software shall support configuration for multi-version service hosting including version-specific endpoint mapping. Rationale: Configuration-driven version mapping allows flexible multi-version deployment. Code Location: |
The software shall reject requests with incompatible major version. Rationale: Major version incompatibility means the interface contract has changed. Error Handling: Return E_WRONG_INTERFACE_VERSION (0x08). Code Location: |
The software shall reject application-level messages that use reserved Service IDs. Rationale: Reserved IDs have special system semantics and must not be used by applications. Error Handling: Return E_UNKNOWN_SERVICE (0x02). Code Location: |
The software shall count dropped unknown messages and rate-limit log output to prevent log flooding. Rationale: Rate-limited logging prevents log files from growing unboundedly during attacks or misconfiguration. Error Handling: Increment counter, log at INFO level at most once per second. Code Location: |
The software shall clamp message processing to the expected length, ignoring excess bytes. Rationale: Clamping prevents buffer overread when processing messages from newer implementations. Error Handling: Process expected length, ignore excess, log size difference. Code Location: |
Traceability¶
Implementation Files¶
src/someip/message.cpp- Message processing with compatibilitysrc/serialization/serializer.cpp- Serializer with default valuessrc/sd/sd_client.cpp- SD client with version matchingsrc/sd/sd_message.cpp- SD message with reserved IDs
Test Files¶
tests/test_message.cpp- Message compatibility teststests/test_serialization.cpp- Serialization compatibility teststests/test_sd.cpp- SD compatibility tests