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 the production someipd binary at the wire level using the someip Python package. No application processes are needed.

  • Application Level Tests: tests the full gateway path from mw::com client through gatewayd and someipd to the 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 and 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. Tests send raw SOME/IP messages and verify responses against the TC8 specification.

DUT Binary#

The protocol conformance DUT is the production someipd binary. It uses vsomeip directly for all SOME/IP network I/O and service discovery. someipd is QM only and is not part of the ASIL-B safety path.

At startup, someipd reads a FlatBuffer binary config (-c flag) that declares the service ID, instance ID, version, and events to offer. The binary initialises a vsomeip application and calls offer_service() for each entry. For TC8, the config is tc8_someipd_config.bin, generated at build time from tests/tc8_conformance/config/tc8_someipd_config.json.

gatewayd is started alongside someipd as a companion process. In the SD-only conformance tests gatewayd idles (its FlatBuffer config declares no service types), but the IPC handshake between someipd and gatewayd must complete before the test proceeds. gatewayd becomes active only in ETS end-to-end tests where a mw::com application offers or consumes the TC8 service.

tc8_itf_conftest.py launches someipd first (it becomes the vsomeip routing manager), waits for an OfferService multicast, then starts gatewayd. Both processes are force-killed (pkill -9) during fixture teardown.

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.

For the per-target port matrix, see tests/tc8_conformance/README.md.

Skipped Test Categories#

The production stack has no mw::com ETS application to generate events, handle methods, or provide field values. The following test modules and individual tests are permanently skipped until a mw::com ETS app is added to the repo.

Table 4 Skipped TC8 Tests (2026-08-11)#

Module / Test

Skip level

Reason

test_event_notification.py

All tests

No event delivery without mw::com ETS app

test_field_conformance.py

All tests

No initial field values or getter/setter handling without mw::com ETS app

test_someip_message_format.py

All tests

No SOME/IP method handling (gatewayd to_num_of_methods=0) without mw::com ETS app

test_service_discovery.py

4 individual tests

Require event notifications before SD lifecycle actions

The 4 individually skipped tests in test_service_discovery.py are:

  • TestSDSubscribeLifecycle.test_tc8_sd_008_stop_subscribe_ceases_notifications

  • TestSDTTLExpiry.test_tc8_sd_014_ttl_expiry_ceases_notifications

  • TestSDSubscribeLifecycleAdvanced.test_ets_155_resubscribe_after_stop

  • TestSDSubscribeLifecycleAdvanced.test_ets_095_subscribe_ttl_expires_no_events

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. 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 offer announcements, find/subscribe responses, SD phase timing, byte-level SD field values, malformed packet robustness, and SD client lifecycle.

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

These tests cover message format (TC8-MSG), event notification (TC8-EVT), field access (TC8-FLD), and TCP transport binding. Domain-specific helpers handle packet construction, subscription workflows, field get/set operations, and TCP stream framing.

Multi-service and Multi-instance#

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

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 and 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 application level test design introduces four planned components. The Enhanced Testability Service (ETS) and Enhanced Testability Client (ETC) implement the TC8 service interface defined in OA TC8 ยง5.1.4, while the Test Orchestrator and Process Orchestrator manage test and process lifecycle.

someipd and gatewayd run as the DUT in the QEMU guest. The Python socket-based tester and pytest run on the host side. tc8_itf_conftest.py manages DUT lifecycle on the QEMU guest. TC8_DUT_IP addresses the QEMU guest and TC8_TESTER_IP addresses the host TAP interface.