SkyV2X · Open Testbed Public · Section 4.2 · Conformance Audit 201/236 passing
TLA-VIS-001  v0.2.0  ·  2026-06-21
4.2 Audit

Conformance audit

The ETSI MEC 032-3 Robot Framework suite runs against Talaia and the verdict ships here. 201 of 236 test cases passing across five service APIs.

4.2.1Verdict

Current verdict

Three values from the audit run, taken directly from /vis/v2/conformance.

Passing

201 / 236

seeded · 196 clean

Under test

5 APIs

MEC 030 · 013 · 012 · 011 · 021

Suite

032-3

Robot Framework

Each cell below represents one test case in the suite. Filled cells passed at the last run; outlined cells are pending.

Passing (201) Pending (35)
4.2.2Method

Method

ETSI GS MEC 032-3 is the conformance specification for the V2X Information Service. It defines test purposes any V2XIS implementation must pass, from request shapes to response codes, error formats, subscription lifecycle, broker discovery. The companion Robot Framework artefact at the ETSI Forge packages those purposes as executable tests.

The audit harness runs the suite against Talaia, parses the Robot output, and exposes the verdict at /vis/v2/conformance. The numbers in 4.2.1 come straight from that endpoint.

Conformance audit pipeline — ETSI MEC 032-3 Robot suite against Talaia Pipeline diagram of the Talaia conformance audit. Step 1: the official ETSI MEC 032-3 Robot Framework test suite, sourced from the ETSI Forge. Step 2: the suite runs against the deployed Talaia platform at mec.skyv2x.com. Step 3: Robot Framework writes its standard output.xml report. Step 4: the audit harness parses output.xml and computes pass-fail counts per resource group. Step 5: the verdict is exposed as JSON under /vis/v2/conformance. Step 6: the verdict is rendered in the public /conformance HTML page with the cell grid and counters. 1 ETSI MEC 032-3 Robot Framework suite sourced from the ETSI Forge · official test purposes 2 run against deployed Talaia https://mec.skyv2x.com/vis/v2/ · live MEC 030 V3.2.1 endpoint surface 3 Robot output.xml standard Robot Framework report — pass-fail per test case 4 audit harness · parse + aggregate computes pass-fail counts per resource group 5a /vis/v2/conformance machine-readable JSON verdict 5b /conformance public HTML page · cell grid + counters
Figure 4.2-1. The audit path, end to end: the suite is external and unmodified, and the verdict reaches this page without a manual step between.mec.skyv2x.com/vis/v2/, the audit harness parses the Robot output.xml, and the verdict is exposed both as JSON under /vis/v2/conformance and as the public HTML page you are reading.
4.2.3Passing

What passes

The suite is run once per implemented service API. Each line is the seeded-regime result; the clean-server figures are four lower in total and reported alongside them at /vis/v2/conformance.

  • MEC 030 · V2X Information /vis/v2, 46 of 47. Provisioning, predicted QoS, publication and the subscription registry.
  • MEC 013 · Location /location/v3, 61 of 68. UE and zone location, area and distance subscriptions.
  • MEC 012 · Radio Network Info /rni/v2, 33 of 33. Every case in the suite.
  • MEC 011 · Application Support /mec_app_support/v2, 41 of 51. Timing, traffic rules and DNS rules pass in full.
  • MEC 021 · Application Mobility /amsi/v1, 20 of 37.

Across all five: ProblemDetails on every 4xx and 5xx with the four required fields, the spec-mandated paths and status codes, and persistent subscription state with the mandated Location headers.

4.2.4Pending

What remains

Thirty-five cases do not pass. None is unexplained, and the reasons fall into three groups.

  • Cases that need resources already in place. Cases that list or delete resources before any case creates them, or that address fixed identifiers from a hosted instance. They pass once those fixtures are seeded, which is the seeded regime above.
  • Paths that differ from the specified ones. Some cases address a version prefix or a resource spelling other than the one the specification defines. A server that serves exactly the specified paths answers 404, and the case is marked failing.
  • One implementation defect of ours. The Location header omits a non-empty deployment API root. Correct in the default deployment, wrong when a root is configured. Recorded, not hidden.

The full residual analysis, case by case, ships with the platform documentation rather than here.

4.2.5Rationale

Why publish

Commercial MEC platforms claiming ETSI conformance ask the integrator to trust the claim, and there is rarely a third-party audit. Talaia publishes the audit instead: the public ETSI suite, run against the live endpoints, with the verdict on this page.

The run is reproducible and every residual is documented, including one that is ours.

Source documents: ETSI GS MEC 030 V3.2.1 [1], ETSI GS MEC 032-3 [6].