P_2026_01-013: Cross-Channel Object Referencing for ASAM OSI Trace Files and OpenLABEL Label
Proposal description
The new MCAP-based multi-channel trace file format of OSI offers the possibility to capture multiple streams of OSI messages for various purposes, like re-simulation, validation, etc. Due to its nature, the format also offers the possibility to store additional, non-OSI channels and meta-data alongside the OSI channels.
This presents the opportunity to store labeling data alongside the OSI raw data, which can be useful for validation purposes, as well as searching and locating suitable traces for further processing.
OpenLABEL provides one potential way of storing labeling data, however currently there exist no conventions for storing this kind of data, nor are there clearly defined cross-referencing conventions, that would allow this kind of labeling to work.
The project proposes to address this situation with the following steps:
- Creation of a clear identification and location convention for OSI trace file data across channels.
- Creation of a clear convention of how labeling data channels can be stored alongside OSI data channels, how their relationship can be specified and how the identification convention is to be used to create the relevant cross-channel linking.
- Providing a proof-of-concept implementation of these mechanisms using a suitable meta-data/labeling format - potentially based of OpenLABEL, or a relevant extension proposal - based on asam-osi-utilities and/or osi-python/osi-cpp.
- Providing a fully worked out example demonstrating the new capabilities in a best-practice style guidance.
As part of the project a look at the current capabilites of ASAM OpenLABEL to tag osi trace data will be taken, which can lead to improvement/extension proposals for a future ASAM OpenLABEL revision (currently OpenLABEL only supports scenario tagging and multi-sensor data stream labeling, neither of which are likely to fully fit the OSI use case).
Detailed background
Problem & Gap (condensed)
- OSI objects are identified by osi3.Identifier (uint64), unique only per message-type context and reused over time — so an ID alone cannot address one object from another channel.
- osi3.ExternalReference (RFC 3986 URI + reverse-DNS type) points outward, not channel-to-channel.
- OSI MCAP channels have topic, schema_id, reverse-DNS metadata (net.asam.osi.trace.channel.*); messages carry channel_id, log_time, publish_time. There is no convention for a channel that cross-references objects in other channels.
- asam-osi-utilities already supports mixed OSI/non-OSI channels (e.g. a JSON channel via MCAPTraceFileChannel / MCAPChannel) — a solid base — but has no URI builder/resolver and no OpenLABEL label-channel helper.
- OpenLABEL v2 (ASCS branch) currently models scenario-level tagging only (no objects/frames), or is intended for multi-sensor raw data labeling.
Core requirement: a reference must be scoped along four axes — topic → message type → object field/id → time (or frame) — to resolve to exactly one object
Solution Sketch (to be finalized in WP1)
A cross-channel object URI, candidate forms to trade off:
- Define a fragment identifier format to be used with URIs pointing to the MCAP file (resolves within the same MCAP file): `#osi//<osi3.MessageType>/<frame-time_ns>/<field_path>/
- Define a new URI scheme, to be used within one MCAP file: osi-mcap:////\<osi3.MessageType>/<frame-time_ns>/<field_path>/
- ExternalReference-native with reserved type = net.asam.osi.trace.object.
The OpenLABEL/other format label channel is bound as a non-OSI MCAP channel (message_encoding=json, schema_encoding=jsonschema) with a reserved role marker and label records that carry these object URIs
Work Packages
WP1 — Concept & cross-channel object-reference URI scheme
Objective: Define the URI scheme and the OpenLABEL label-channel binding.
Tasks:
- Capture and refine requirements for overall solution
- Evaluate candidate forms 1/2/3 or other potential approaches against requirements; define URI grammar (ABNF) + resolution semantics (time/ frame scoping, ID-reuse, StreamingUpdate handling)
- Define the label-channel binding (topic naming, encoding, reserved net.asam.osi.trace.channel.* metadata)
- Write a concise design note and an OSI change-request draft.
Effort: 20PD (WG) + 6PD (Support)
WP2 — Python reference PoC in asam-osi-utilities
Objective: A clean, well-documented Python implementation that proves the concept and is precise enough to serve as the reference for the C++ port.
Tasks:
- URI builder/resolver
- OpenLABEL JSON label-channel writer + reader on top of MCAPChannel / the multi-channel writer
- one worked example that writes an MCAP with an OSI channel plus a cross-referencing OpenLABEL label channel
- round-trip read + resolve
- focused unit tests.
Effort: 15PD (WG) + 7PD (Support)
WP3 — C++ analogous port (agent-assisted)
Objective: Mirror the Python API/example in C++ at low incremental cost by translating the well-specified Python PoC (agent-assisted), then hardening.
Tasks:
- Port URI utils + label-channel writer/reader to MCAPTraceFileWriter / MCAPTraceFileChannel
- parity example
- smoke/interop test against a Python-written file.
Effort: 15PD (WG) + 3 PD (Support, kept low by reuse of the WP2 spec + agent assistance).
WP4 — End-to-end example, lightweight validation & input to WG standardization
Objective: Demonstrate the full flow and feed the results into ASAM OSI and ASAM OpenLABEL further standardization activities.
Tasks:
- One end-to-end example (single-/multi-sensor OSI trace → derived OpenLABEL labels in the same MCAP);
- a lightweight resolvability check (dangling / ambiguous / time-mismatched references);
- short usage docs;
- a CCB-/Standard-facing package (presentation + notes) that consolidates the design, the PoC findings, and open decisions for the groups to take forward.
Effort: 15PD (WG) + 3 PD (Support).
Backward compatibility
The extensions to ASAM OSI are going to be fully backward-compatible extensions. Any extension/refinement proposal for ASAM OpenLABEL is likely to be fully backward-compatible.
Completion criteria / deliverables
Define what needs to be achieved to finish the epic. Each criterion can be met by finishing one or more issues.
Project type
Implementation
Affected standards
Participants
| Assignee: | @jdsika |
| Initiating Companies: | BMW AG, PMSF IT Consulting |
| ASAM Office Responsible (OR): | @AhmedSadek |
Proposal scheduling
| Estimated time | Budget | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
|
- Expected project group effort: 65PD (assumption of 13 weeks project duration with 1PD per participant per week, baseline of 5 participants)
- Expected support effort: 19PD