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.

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

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 + 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.

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.