TC8 SOME/IP Conformance Testing#

Overview#

OPEN Alliance TC8 defines conformance tests for automotive SOME/IP implementations. The TC8 test suite has two scopes:

  • Protocol Conformance — tests someipd at the wire level using the someip Python package. No application processes are needed.

  • Application-Level Tests — tests the full gateway path (mw::com client → gatewayd → someipd → network) using C++ apps built on score::mw::com. These tests are stack-agnostic.

Both scopes live under tests/tc8_conformance/ and share the tc8 / conformance Bazel tags. For setup instructions and test details, see tests/tc8_conformance/README.md.

Test Scope Overview#

Protocol Conformance#

Protocol conformance tests exercise the SOME/IP stack at the wire protocol level. The DUT is someipd in standalone mode. Tests send raw SOME/IP messages and verify responses against the TC8 specification.

Standalone Mode#

someipd normally waits for gatewayd to connect via LoLa IPC before offering services. The --tc8-standalone flag removes this dependency: someipd skips the IPC proxy setup and calls offer_service() directly.

This keeps protocol conformance tests simple — no process ordering, no FlatBuffers config, and fewer failure modes. See src/someipd/main.cpp.

Port Isolation and Parallel Execution#

Each Bazel TC8 target runs in its own OS process and receives unique SOME/IP port values via the Bazel env attribute. Three environment variables control port assignment:

TC8_SD_PORT

SOME/IP-SD port. Set in both the vsomeip config template (replacing the __TC8_SD_PORT__ placeholder) and read by the Python SD sender socket at module import time via helpers/constants.py. The SOME/IP-SD protocol requires SD messages to originate from the configured SD port; satisfying this does not require a fixed port — it requires only that both sides use the same port, which is guaranteed because both the vsomeip config and the Python constants read the same env var.

TC8_SVC_PORT

DUT UDP (unreliable) service port. Replaces the __TC8_SVC_PORT__ placeholder in config templates.

TC8_SVC_TCP_PORT

DUT TCP (reliable) service port. Replaces the __TC8_SVC_TCP_PORT__ placeholder in config templates. Only set for targets that use reliable transport (tc8_message_format, tc8_event_notification, tc8_field_conformance).

All three constants default to the historical static values (30490 / 30509 / 30510) when the environment variables are not set, preserving backward compatibility for local development runs without Bazel.

Port Assignment per Target

Target

TC8_SD_PORT

TC8_SVC_PORT

TC8_SVC_TCP_PORT

exclusive

tc8_service_discovery

30490

30500

—

no

tc8_sd_phases_timing

30491

30501

—

yes (timing)

tc8_message_format

30492

30502

30503

no

tc8_event_notification

30493

30504

30505

no

tc8_sd_reboot

30494

30506

—

yes (lifecycle)

tc8_field_conformance

30495

30507

30508

no

tc8_sd_format

30496

30509

—

no

tc8_sd_robustness

30497

30510

—

no

tc8_sd_client

30498

30511

—

yes (lifecycle)

tc8_multi_service

30499

30512

30513

no

The four medium targets (tc8_service_discovery, tc8_message_format, tc8_event_notification, tc8_field_conformance) run in parallel. The three large/exclusive targets (tc8_sd_phases_timing, tc8_sd_reboot, tc8_sd_client) retain the exclusive tag for timing accuracy or lifecycle correctness. The remaining medium targets (tc8_sd_format, tc8_sd_robustness, tc8_multi_service) also run in parallel.

Test Module Structure#

Each TC8 area has a test module (pytest) and one or more helper modules. The diagrams below show the dependencies grouped by TC8 domain. In both diagrams, blue boxes represent test modules and green boxes represent shared helper modules. Dashed arrows indicate internal helper-to-helper dependencies.

Service Discovery (SD)#

The Service Discovery tests (TC8-SD) verify SOME/IP-SD multicast offer announcements, unicast find/subscribe responses, SD phase timing, byte-level SD field values, malformed packet robustness, and SD client lifecycle. Six test modules cover the SD test suite, sharing five helpers for socket management, SD packet construction, malformed packet injection, assertion, and timestamped capture.

Message Format, Events, Fields, and TCP Transport (MSG / EVT / FLD / TCP)#

The remaining protocol tests are grouped into message format (TC8-MSG), event notification (TC8-EVT), field access (TC8-FLD), and TCP transport binding (SOMEIPSRV_RPC / OPTIONS). Each domain has a dedicated test module. test_someip_message_format has been extended with three additional classes covering basic service identifiers (SOMEIPSRV_BASIC_01–03), response field assertions (SOMEIPSRV_ONWIRE_01/02/04/06/11, SOMEIPSRV_RPC_18/20), and fire-and-forget / error handling (SOMEIPSRV_RPC_05–10, ETS_004/054/059/061/075). Domain-specific helpers handle packet construction, subscription workflows, field get/set operations, and TCP stream framing, while sd_helpers provides shared SD primitives used across all three test modules.

Multi-service and Multi-instance#

test_multi_service.py verifies that someipd correctly handles vsomeip configurations that declare multiple service entries, and that each service instance advertises its own distinct UDP port in the SD endpoint option.

  • SOMEIPSRV_RPC_13 — confirms that the vsomeip config successfully loads multiple service entries and that the DUT offers its primary service (0x1234/0x5678) with a well-formed SD stream.

  • SOMEIPSRV_RPC_14 — confirms that each service instance in the config is assigned a distinct UDP port and that the offered service’s SD IPv4 endpoint option reflects the configured port.

The DUT uses config/tc8_someipd_multi.json — a vsomeip configuration that declares two services (0x1234/instance 0x5678 and 0x5678/instance 0x0001) on separate ports, ensuring port routing correctness at the SD layer.

All requirement IDs use the comp_req__tc8_conformance__ prefix.

Application-Level Tests#

Application-level tests verify the full gateway pipeline end-to-end. A service (mw::com Skeleton) and client (mw::com Proxy) communicate through gatewayd + someipd. Because both apps use the mw::com API only, the same test code works with any SOME/IP binding.

Note

Application-level tests are planned. See tests/tc8_conformance/application/README.md for the intended scope.

Planned Topology#

Stack-Agnostic Design#

The test apps depend only on score::mw::com. Switching the SOME/IP stack requires changing the deployment config, not test code.

Planned Components#

The orchestrator starts the ETS application, gatewayd, and someipd via conftest.py subprocess fixtures — the same subprocess.Popen pattern used for the standalone someipd fixture. The S-CORE ITF framework is the preferred long-term orchestrator for multi-node or structured CI reporting scenarios.

CI/CD Integration#

Protocol conformance tests run on ubuntu-24.04 GitHub Actions runners under build_and_test_host.yml. The someipd process runs as a local subprocess in a dedicated CI step that first adds the loopback multicast route, then runs all TC8 targets:

sudo ip route add 224.0.0.0/4 dev lo
bazel test --test_tag_filters=tc8 --test_output=all \
           --test_env=TC8_HOST_IP=127.0.0.1 //tests/tc8_conformance/...

TC8_HOST_IP=127.0.0.1 is passed via --test_env. The DUT fixture writes this address into the SOME/IP config template (replacing the __TC8_HOST_IP__ placeholder), keeping all traffic on loopback.

Each TC8 target receives unique TC8_SD_PORT, TC8_SVC_PORT, and (where applicable) TC8_SVC_TCP_PORT values via the Bazel env attribute, as described in the Port Isolation and Parallel Execution section above. The medium targets (tc8_service_discovery, tc8_message_format, tc8_event_notification, tc8_field_conformance, tc8_sd_format, tc8_sd_robustness, tc8_multi_service) run concurrently. The three exclusive targets (tc8_sd_phases_timing, tc8_sd_reboot, tc8_sd_client) carry the exclusive tag and run serially for timing accuracy or lifecycle correctness.

Application-level tests (when implemented) will follow the same pattern. If multi-node isolation is needed, the Docker Compose setup at tests/integration/docker_setup/ can be extended.

TC8 Specification Alignment Analysis#

This section maps the 230 test cases in Chapter 5 of the OPEN Alliance TC8 ECU Test Specification Layer 3-7 v3.0 (October 2019) to the current implementation status. It answers three questions for every TC8 group:

  1. What is already tested and passing?

  2. What can be tested today without any new software?

  3. What requires new software before the tests can run?

For the full test case catalog see tests/tc8_conformance/tc8_ecu_test_chapter5_someip_v3.0_oct2019.md.

The specification organizes Chapter 5 into two top-level groups:

  • SOME/IP Server Tests (SOMEIPSRV_*, 93 items, Section 5.1.5) — wire-level protocol checks. Only someipd and a raw socket are needed. No application code is required.

  • Enhanced Testability Service Tests (SOMEIP_ETS_*, 137 items, Section 5.1.6) — behavior tests that range from wire-level SD tests (needing only someipd) to full-pipeline serialization tests that require a C++ test application.

Coverage at a Glance#

The table below shows the top-level status for all five TC8 test groups.

TC8 Group

Total

✅ Tested

⚠ Can add

Infrastructure needed

SOMEIPSRV Protocol (§5.1.5)

93

93

0

N/A — all wire-level tests complete

ETS SD Protocol (§5.1.6 SD)

74

60

0

14 tests blocked — ETS application required (ETS_089/096/097/103/146–151/164/166–168 require ETS C++ application)

ETS Robustness (§5.1.6 robustness)

14

14

0

N/A — all tests complete

ETS Serialization / Echo (§5.1.6 echo)

44

0

0

ETS application + gatewayd — see ETS Application Gap

ETS Client / Control (§5.1.6 client)

5

3

0

2 of 5 require ETS control methods — see ETS Application Gap

Key points:

  • The first three groups (181 specification items total) need only someipd and the existing pytest framework. 167 of these items have passing tests; 14 ETS SD items remain blocked pending the ETS C++ application (see ETS Application Gap).

  • The last two groups (49 tests total) are blocked. They cannot be written until a C++ ETS test application is implemented. See ETS Application Gap for what is needed.

Current Implementation#

The test suite contains 183 test functions across 10 pytest modules.

Implemented Test Modules

Module

Tests

TC8 Coverage

test_service_discovery.py

38

TC8-SD-001 through SD-008, SD-011, SD-013, SD-014; SOMEIPSRV_SD_MESSAGE_01–06/14–19; SD_BEHAVIOR_03/04; all ETS SD lifecycle tests

test_sd_phases_timing.py

2

TC8-SD-009, SD-010

test_sd_reboot.py

4

TC8-SD-012 (reboot flag + session ID reset)

test_sd_format_compliance.py

43

FORMAT_01–07/09–28 (all SD header and entry fields); OPTIONS_01–06/08–14 (IPv4 endpoint + multicast options); SD_MESSAGE_07–09/11 (OfferService and Subscribe entry raw fields)

test_sd_robustness.py

31

Malformed SD entry and option handling; SD framing errors; subscribe edge cases (ETS robustness group)

test_sd_client.py

5

ETS_081/082/084 (SD client stop-subscribe, reboot detection)

test_someip_message_format.py

42

TC8-MSG-001 through MSG-008; SOMEIPSRV_RPC_01/02/05–10/17–20; SOMEIPSRV_OPTIONS_15 (TCP transport binding); SOMEIPSRV_BASIC_01–03; SOMEIPSRV_ONWIRE_01/02/04/06/11; ETS_004/054/059/061/075; SOMEIP_ETS_068 (unaligned TCP), SOMEIP_ETS_069 (unaligned UDP)

test_event_notification.py

9

TC8-EVT-001 through EVT-006; SOMEIPSRV_RPC_17 (TCP notification); SOMEIPSRV_RPC_15 (cyclic rate); SOMEIPSRV_RPC_16 (on-change notification)

test_field_conformance.py

6

TC8-FLD-001 through FLD-004; SOMEIPSRV_RPC_17 (TCP field GET/SET)

test_multi_service.py

3

SOMEIPSRV_RPC_13 (multi-service config validity); SOMEIPSRV_RPC_14 (instance port isolation)

All tests use someipd in --tc8-standalone mode as the DUT, exercised via raw UDP and TCP sockets from pytest. No gatewayd or mw::com application is involved.

SOME/IP Server Tests (SOMEIPSRV_*, 93 items)#

These 93 tests check the SOME/IP wire protocol at the byte level. The DUT is someipd in standalone mode. Each test sends a raw UDP or TCP packet and checks the DUT’s response. No C++ application code or gatewayd is needed.

The table below uses these status labels:

  • Complete — every specification item in this category has a passing test.

  • Near-complete — one or two items do not yet have a test, but they can be added using the existing framework. No new software is needed.

  • Complete (loopback skip) — all tests are written and pass on real hardware. Tests that require a physical network card for multicast skip automatically in CI (loopback has no multicast NIC).

SOMEIPSRV Coverage Mapping

TC8 Category (Section)

Total

Written

Status

Notes

SD Message Format (5.1.5.1)

27

27

Complete

All SD SOME/IP header fields (Client ID, Session ID, Protocol Version, Interface Version, Message Type, Return Code, Reboot flag, Unicast flag, Reserved) and all OfferService and SubscribeAck entry fields (FORMAT_01 through FORMAT_28) have dedicated byte-level assertions in test_sd_format_compliance.py.

SD Options Array (5.1.5.2)

15

15

Complete (7 skip in CI)

IPv4 Endpoint Option (OPTIONS_01–07), IPv4 Multicast Option (OPTIONS_08–14), and TCP Endpoint Option (OPTIONS_15) are all tested. The 7 multicast sub-field tests (OPTIONS_08–14) skip in loopback CI because they require a real multicast network interface. They run and pass on hardware with a physical Ethernet card.

SD Message Entries (5.1.5.3)

17

17

Complete

Tested: FindService responses (SD_MESSAGE_01–06), OfferService raw entry fields including entry Type byte and both option-run fields (SD_MESSAGE_07–09), Subscribe request entry Type byte (SD_MESSAGE_11), SubscribeAck entry (SD_MESSAGE_13), NAck conditions (SD_MESSAGE_14–19), and Stop Subscribe raw entry format (SD_MESSAGE_12). All items covered.

SD Communication Behavior (5.1.5.4)

4

4

Complete

Repetition phase doubling (SD_BEHAVIOR_01), Main Phase cyclic offers (SD_BEHAVIOR_02), and FindService response timing (SD_BEHAVIOR_03/04 — wall-clock assertions checking the DUT responds within request_response_delay * 1.5) are all covered. StopSubscribe behavior (SD_BEHAVIOR_06) is covered by TC8-SD-008. SD_BEHAVIOR_05 (client reaction to StopOffer) does not apply: the DUT is a server only and has no active client subscriptions to cancel.

Basic Service Identifiers (5.1.5.5)

3

3

Complete

Service ID (BASIC_01), Instance ID (BASIC_02), and event notification method ID bit — bit 15 = 1 (BASIC_03) — are all verified. Note: vsomeip 3.6.1 fails BASIC_03 (sends a RESPONSE to event-ID messages). See Known SOME/IP Stack Limitations.

On-Wire Format (5.1.5.6)

10

10

Complete

Protocol version, message type, request/response ID echo, interface version, return codes, and error responses for unknown service or method are all verified (ONWIRE_01–07/10–12) in test_someip_message_format.py.

Remote Procedure Call (5.1.5.7)

17

17

Complete

Tested: TCP request/response (RPC_01/02), Fire-and-Forget (RPC_04/05), return code handling (RPC_06–10), field getter/setter (RPC_03/11), multiple service instances (RPC_13/14), cyclic notification rate (RPC_15), on-change-only notification (RPC_16), TCP event and field notification (RPC_17), error header echo (RPC_18/19/20). All items covered.

Summary: All 93 SOMEIPSRV items have passing tests.

ETS Tests (SOMEIP_ETS_*, 137 items)#

The ETS test cases split into two tracks based on what infrastructure they need.

Track A — Wire-level tests (88 items, pytest)

These tests check the SOME/IP wire protocol directly. They use someipd in standalone mode and send raw packets — exactly the same setup as the SOMEIPSRV tests above. All wire-level ETS tests are now implemented; 14 tests in the ETS SD Protocol group remain blocked pending the ETS C++ application.

ETS SD Protocol (74 items)

This group covers Service Discovery at the wire level: FindService, SubscribeEventgroup with various option types, NAck conditions, session ID behavior, TTL expiry, reboot detection, and multicast/unicast interactions.

Status: 60 of 74 implemented (14 blocked — require ETS application).

All wire-level ETS SD tests that can run without the ETS C++ application are now implemented. The 60 implemented tests cover session ID behavior, FindService responses, subscribe edge cases, malformed SD entries and options, TTL expiry, reboot detection, and multicast/unicast interactions.

Implemented examples:

  • SOMEIP_ETS_088 — two subscribes with the same session ID

  • SOMEIP_ETS_091 — session ID increments correctly

  • SOMEIP_ETS_092 — TTL=0 stop-subscribe

  • SOMEIP_ETS_120 — subscribe endpoint IP matches tester

  • SOMEIP_ETS_111–142 — malformed SD entries and options (robustness)

  • SOMEIP_ETS_081/082/084 — SD client stop-subscribe, reboot detection

ETS SD Protocol — Blocked Tests (14 items, require ETS application)

The following 14 ETS SD test cases cannot be implemented without the ETS C++ application:

  • SOMEIP_ETS_089 — suspendInterface control method required

  • SOMEIP_ETS_096 — TCP connection prerequisite for subscription (needs ETS app for TCP server)

  • SOMEIP_ETS_097 — TCP reconnection recovery (needs ETS app for TCP server)

  • SOMEIP_ETS_103 — SD_ClientServiceGetLastValueOfEventTCP (TCP event delivery, needs ETS app)

  • SOMEIP_ETS_146 — resetInterface control method required

  • SOMEIP_ETS_147–151 — triggerEvent* methods required (event push triggers)

  • SOMEIP_ETS_164 — suspendInterface control method required

  • SOMEIP_ETS_166–168 — TestField* methods required (field read/write via ETS app)

These are tracked in ETS Application Gap and will be unblocked when the ETS C++ application is implemented.

ETS Robustness (14 items)

These tests send wrong protocol versions, wrong message types, wrong IDs, truncated messages, oversized messages, and unaligned packets.

Status: 14 of 14 implemented.

All implemented:

  • SOMEIP_ETS_068 — unaligned SOME/IP messages over TCP (TC8-TCP-009 in test_someip_message_format.py)

  • SOMEIP_ETS_069 — unaligned SOME/IP messages over UDP (TC8-UDP-001)

  • SOMEIP_ETS_074/075/076/077/078 — wrong interface version, message type, method ID, service ID, protocol version

  • SOMEIP_ETS_054/055 — length field zero or less than 8 bytes

  • SOMEIP_ETS_004 — burst of 10 sequential requests

Track B — Tests requiring an ETS application (49 items)

These tests cannot run yet because they require a C++ test application that does not exist. The tests cannot be written until that application is built. This is the only infrastructure gap for ETS tests.

What is the ETS application?

It is a small C++ program (a score::mw::com Skeleton) that implements the TC8 service interface defined in Section 5.1.4 of the specification. The planned location is tests/tc8_conformance/application/ (the directory structure and README are already in place, but no code exists yet). It must expose:

  • Echo methods — receive a value and return it unchanged (echoUINT8, echoUINT8Array, echoUTF8DYNAMIC, echoUNION, and ~40 others). These let the tester verify that the full pipeline (mw::com Skeleton → gatewayd → someipd → network) serializes every SOME/IP data type correctly.

  • Event triggers — fire an event on demand (triggerEventUINT8, triggerEventUINT8Reliable, etc.)

  • Field accessors — getter, setter, and notifier for TC8 test fields

  • Control methods — resetInterface, suspendInterface, clientServiceActivate / clientServiceDeactivate

ETS Serialization / Echo (44 items) SOMEIP_ETS_001–053, 063–073

The tester sends an echo request with a specific data value. The DUT must return the same value through the full pipeline. This validates the Payload Transformation component inside gatewayd.

Status: 0 of 44 implemented. These tests cannot be written until both the ETS application and the Payload Transformation component in gatewayd exist and are working correctly.

Data types covered by echo tests: UINT8, INT8, INT64, FLOAT64, arrays (static and dynamic, 1D and 2D), strings (UTF-8 and UTF-16, fixed and dynamic length), unions, enums, bitfields, E2E-protected messages, and common data type combinations.

ETS Client / Control (5 items)

Three of these (SOMEIP_ETS_081/082/084) are already implemented in test_sd_client.py because they only need wire-level SD messages. The remaining two (SOMEIP_ETS_089/164) use resetInterface and suspendInterface control methods, which require the ETS application.

Status: 3 of 5 implemented; 2 blocked on ETS application.

Test Framework Suitability#

Framework Assessment per TC8 Group

TC8 Test Group

Count

Framework needed

Current status

SOMEIPSRV Protocol (all)

93

pytest

✅ Complete — all 93 tests written and passing.

ETS SD Protocol

74

pytest

✅ Complete — all 60 wire-level tests written and passing. 14 tests blocked on ETS application (see ETS Application Gap).

ETS Robustness

14

pytest

✅ Complete — all 14 tests written and passing.

ETS Serialization / Echo

44

ETS application + gatewayd + pytest

0 of 44 implemented. Blocked — ETS application and Payload Transformation in gatewayd do not exist yet.

ETS Client / Control

5

3 use pytest; 2 need ETS application

3 of 5 implemented (ETS_081/082/084 in test_sd_client.py). 2 tests (ETS_089/164) blocked on ETS application.

Framework recommendation:

For all tests, pytest is the test framework. Wire-level tests run entirely within the pytest process. Application-level tests extend conftest.py with a subprocess fixture that starts the ETS application, gatewayd, and someipd in order — the same subprocess.Popen pattern used for the standalone someipd fixture. Adopt S-CORE ITF if multi-node isolation or structured CI reporting becomes necessary.

What is Needed to Reach 100% Coverage#

The table below lists the remaining actions in priority order.

#

Action

Unlocks

Details

1

✅ DONE — Write missing wire-level tests

21 tests added

All 21 missing wire-level tests have been implemented (21 new test functions added in this milestone). SD_MESSAGE_12, RPC_15, RPC_16, all ETS SD Protocol wire-level tests, and all ETS Robustness tests are now written and passing.

2

Implement the ETS application (mw::com Skeleton)

49 tests

Write the C++ service application in tests/tc8_conformance/application/. The directory structure and README are already in place. The application must implement all echo methods (echoUINT8, echoUINT8Array, echoUTF8DYNAMIC, and ~40 others), event triggers, field accessors, and control methods (resetInterface, suspendInterface, clientServiceActivate).

3

Verify Payload Transformation in gatewayd

44 tests (same as action 2)

Serialization echo tests pass only when gatewayd correctly serializes and deserializes all TC8 data types through the full pipeline. Verify each type: UINT8/INT8/FLOAT64, static and dynamic arrays, UTF-8 and UTF-16 strings, unions, enums, bitfields, and common data type combinations.

4

Add ETS process orchestration to conftest.py

49 tests (same as action 2)

Add a pytest fixture that starts the ETS application, gatewayd, and someipd in order and tears them down after the test. A simple subprocess.Popen fixture is sufficient. Adopt S-CORE ITF later if multi-node isolation is needed.

5

Assess E2E protection support

2 tests

SOMEIP_ETS_034 (echoUINT8E2E) and SOMEIP_ETS_149 (triggerEventUINT8E2E) require E2E middleware integration. Assess whether mw::com and gatewayd support E2E protection and configure it if needed.

Transport Layer Tests — Status#

The following ETS test cases involve transport layer scenarios.

Spec ID

Title

TCP Scenario

Status

SOMEIP_ETS_035

echoUINT8RELIABLE

Request/response via TCP

Blocked — needs ETS app

SOMEIP_ETS_037

echoUINT8RELIABLE_client_closes_TCP_connection_automatically

TCP lifecycle persistence

Blocked — needs ETS app

SOMEIP_ETS_068

Unaligned_SOMEIP_Messages_overTCP

Multiple SOME/IP messages in one TCP packet

✅ Implemented — TC8-TCP-009 in test_someip_message_format.py

SOMEIP_ETS_069

Unaligned_SOMEIP_Messages_overUDP

Multiple SOME/IP messages in one UDP datagram

✅ Implemented — TC8-UDP-001 in test_someip_message_format.py

SOMEIP_ETS_086

Eventgroup_EventsAndFieldsAll_2_TCP

TCP eventgroup with initial field delivery

Blocked — needs ETS app

SOMEIP_ETS_096

SD_Check_TCP_Connection_before_SubscribeEventgroup

TCP prerequisite for subscription

Blocked — needs ETS app

SOMEIP_ETS_097

SD_Client_restarts_tcp_connection

TCP reconnection recovery

Blocked — needs ETS app

SOMEIP_ETS_068 and SOMEIP_ETS_069 are the only transport layer tests that can be tested at the wire level (no application needed). Both are implemented. The TCP helper functions tcp_send_concatenated() and tcp_receive_n_responses() live in helpers/tcp_helpers.py; the UDP equivalents udp_send_concatenated() and udp_receive_responses() live in helpers/udp_helpers.py. All remaining TCP tests require the ETS application and Payload Transformation in gatewayd.

Known SOME/IP Stack Limitations#

The following table records the known limitations of vsomeip 3.6.1 against the OA TC8 v3.0 specification. This table must be reviewed and updated whenever the SOME/IP stack version changes.

Each test listed here is decorated with @pytest.mark.xfail(strict=True) so that CI passes despite the known non-conformance. strict=True ensures that if the limitation is fixed in a future stack version, the unexpected pass (XPASS) will cause CI to fail, prompting removal of the marker.

OA Spec Reference

Specification Requirement

vsomeip 3.6.1 Actual Behaviour

Test Result

§5.1.5.3 — SOMEIPSRV_SD_MESSAGE_19

SubscribeEventgroup with reserved bits set in the entry MUST be responded to with a NAck (SubscribeEventgroupAck with TTL = 0).

Sends a positive SubscribeEventgroupAck (TTL > 0) regardless of reserved bits.

XFAIL — test_service_discovery::TestSDSubscribeNAck::test_sd_message_19_reserved_field_set

§5.1.5.5 — SOMEIPSRV_BASIC_03

When the DUT receives a message with method_id bit 15 = 1 (event notification ID), it MUST NOT send a RESPONSE (message_type 0x80).

Sends a RESPONSE (message_type 0x80) for event-ID messages even though the spec prohibits it.

XFAIL — test_someip_message_format::TestSomeipBasicIdentifiers::test_basic_03_event_method_id_no_response

§5.1.5.7 — SOMEIPSRV_RPC_08

The DUT MUST NOT send a reply to a REQUEST message that already carries a non-zero return code.

Processes the REQUEST normally and sends a RESPONSE, ignoring the return code field.

XFAIL — test_someip_message_format::TestSomeipFireAndForgetAndErrors::test_rpc_08_request_with_error_return_code_no_reply