Consider an illustrative ACC cut-in scenario: another vehicle enters the lane and the ACC function requests braking. An engineer needs to assess whether the response matches the expected behavior.
That assessment depends on connecting sensor observations, vehicle signals and function outputs in time. ADTF can provide a workflow for recording, processing and replaying those data. To make the event useful for later investigation, the setup needs to preserve the selected streams, their timing and the configuration required to use them again.
Capture the data needed for the question
Start with the behavior you want to assess and select the data needed to investigate it. Depending on the function and available interfaces, the cut-in example could require:
- Camera images to inspect the visible situation.
- LiDAR data to examine the sensor observations around the maneuver.
- Vehicle and function signals, such as speed, ACC state and a braking request, where available.
Camera and LiDAR describe the origin of the data. CAN and Ethernet describe possible interfaces. The source components must match the actual devices, protocols and data formats.
An important architectural advantage of ADTF is that a function's data path can be configured separately from the recording. The function receives the streams it needs for its task, while the Recorder can capture additional streams for later investigation. This helps avoid unnecessary processing in the function while preserving a broader view of the event.
During subsequent testing sessions, engineers can route recorded streams to processing and visualization components, inspect the additional context and trace the observed behavior. Focused processing and retained context work together to support performance and systematic debugging. ADTF streaming architecture
The source components provide samples through sample streams. Connect the streams needed for the investigation to the ADTF Recorder, which provides input pins for the connections. Before the drive, check that the required streams arrive and that recording performance and storage are sufficient for the expected data rate.
Make timing part of capture
Data from different devices may carry timestamps from different clocks. A meaningful comparison requires a defined relationship between those times.
ADTF's reference-clock interfaces provide mechanisms such as Sync2Ref, which maps external timestamps to ADTF Stream Time and can account for clock offset and drift. Capture and time synchronization therefore belong in the design of the input stage. Their implementation depends on the selected source components and clock configuration.
Document what each timestamp represents. A timestamp assigned at the source and the time a sample reaches the Recorder describe different points in the data path. Without that distinction, an apparent delay between a sensor observation and a function response can be misinterpreted.
Keep the recording and its context together
The Recorder stores the selected streams in a container file. In its default time-base mode, it retains samples, stream-type updates and triggers with the stream time at arrival at the Recorder. Sample timestamps can differ from that arrival time. Recorder timing documentation
Keep the recording together with the information needed to interpret and replay it:
- The ADTF release, packages and component versions.
- The session configuration, function software version and parameters.
- Required stream descriptions, decoding information and calibration data.
- The clock configuration, event time window and expected behavior.
This bundle gives another engineer a defined starting point for investigating the event.
Configure playback for the investigation
For playback, the ADTF Player acts as a streaming source. Its outputs feed sample streams connected to the required processing or visualization components. The separate Playback Service supports file playback and the playback timeline.
By default, the Player and Playback Service use chunk timestamps, representing arrival at the Recorder. This revisits the data at that recording point. A configuration using sample timestamps can support an investigation concerned with timing at the original sources. Select and document the appropriate reader and timing configuration for the question being investigated. Player timing documentation
Also define what the replay should do:
- Inspect the recorded reaction: replay the captured function outputs alongside the relevant input and vehicle data.
- Run the function again: supply recorded inputs to a configured function implementation and collect newly calculated outputs. This requires the function, its dependencies and its execution configuration.
These setups answer different questions. Recorded inputs remain fixed when the function produces different outputs. A test in which the vehicle or environment must react to those outputs needs a suitable feedback-based setup.
Inspect behavior against the test criteria
For the illustrative cut-in, a useful analysis view would place selected sensor observations, ACC state, braking request and vehicle response on a documented timeline.
The engineer can then inspect the sequence around the event and compare the observed behavior with the test criteria. Missing data, an unexpected signal transition or a different relationship between inputs and outputs can guide the next investigation step.
A replay makes selected data available for inspection. A pass or fail verdict still needs defined criteria and the appropriate evaluation logic. Similarly, repeating the same input recording does not by itself establish identical application results. Software, parameters, timing and execution settings remain part of the comparison.
The practical benefit is a shared investigation setup: another engineer can revisit the selected event using a known dataset and documented configuration. An observed difference can then be discussed against that common baseline.
Evaluate one workflow with ADTF
A useful first evaluation can stay focused: one recording, one event window and one engineering question. Identify the source interfaces, define the timing configuration and choose the output that will help answer the question. For the ACC example, that could be a timeline connecting a recorded braking request to the corresponding sensor and vehicle data.
At digitalwerk, we support teams in configuring ADTF components and integrating recording, playback and analysis into their engineering workflows.
Which recording-to-replay workflow would you like to evaluate with ADTF? Explore ADTF and bring one dataset or data-source description and the question you need to answer.