4. Data pipeline architecture for automated evaluation

An automated injury-limit evaluation is only as trustworthy as the data pipeline that feeds it. Before a single criterion such as HIC, BrIC, or Nij can be computed, the pipeline must solve three problems that are deceptively difficult in real crash-test environments: reading heterogeneous file formats, placing every signal on a common time base, and binding each signal to the physical channel and occupant location it actually represents. This section describes a reference architecture that handles all three, with concrete implementation guidance for ISO MME, Diadem, and RPC inputs.

Reference pipeline architecture

A robust pipeline is organized as a sequence of stages with explicit, inspectable artifacts between them. The first stage is ingestion, which parses each source file into a neutral in-memory representation: a set of channels, each with a name, unit, sample rate, time vector, and data array, plus file-level metadata (test ID, vehicle configuration, sensor list). The second stage is time synchronization, which resamples or aligns all channels onto a single evaluation time base. The third stage is channel mapping, which resolves each neutral channel to a canonical measurement identifier used by the evaluation rules. Only after mapping does the evaluation engine run, and its outputs are written to a result store keyed by test ID and rule version.

Ingestion: normalizing three very different formats

ISO MME files are XML-based and describe channels with explicit metadata, but the same physical signal may appear under different names across test houses. The parser should read the channel list, unit, and sample rate, and immediately validate that the declared unit matches the expected dimension (for example, acceleration in g or m/s²). A unit mismatch is a hard error, not a warning: silently treating m/s² as g scales HIC by roughly a factor of ten and produces a plausible-looking but completely wrong result.

Diadem files (TDM/TDMS) store channels in hierarchical groups. The group path often encodes the occupant and body region, for example /Dummy/Head/AccX. The ingestion layer should preserve the full group path as part of the channel's provenance, because it is frequently the only reliable clue for mapping. RPC files are a different animal: they describe road or input profiles rather than measured response, and their sample rates are typically far lower. They are ingested for context and for input reconstruction, not for injury evaluation, and should be tagged accordingly so the mapping stage does not attempt to bind them to occupant channels.

Time synchronization: one clock, one origin

Crash-test channels rarely share a sample clock. The accelerometer array may run at 10 kHz, the load cells at 20 kHz, and the vehicle CAN bus at 100 Hz. Synchronization has two distinct parts. First, establish a common time origin: the impact event, usually detected from a dedicated trigger channel or from the first sustained acceleration above a threshold. Second, resample every channel onto a uniform evaluation grid, typically 10 kHz for injury criteria, using an anti-aliasing filter before downsampling and zero-order hold or linear interpolation for upsampling.

A practical implementation records, for each channel, the original rate, the detected offset relative to the trigger, and the resampling method applied. If the measured offset between two nominally synchronized channels exceeds a tolerance such as 1 ms, the pipeline should raise a flag rather than silently correcting it. In the example configuration below, the trigger is channel TRIG_IMPACT, the evaluation grid is 10 kHz, and the drift tolerance is 1 ms.

sync:
  trigger_channel: TRIG_IMPACT
  trigger_threshold_g: 3.0
  evaluation_rate_hz: 10000
  resample:
    downsample_filter: butterworth_lowpass
    cutoff_hz: 1650
    upsample_method: linear
  drift_tolerance_ms: 1.0
  on_drift_exceeded: flag_and_continue

Channel mapping: from names to canonical identifiers

Mapping is where most automation failures originate. The evaluation rules do not care that a channel is called Head_Acc_X in one file and HIC_Ax in another; they need a canonical identifier such as OCC_DRIVER.HEAD.AX with a defined sign convention. The mapping layer should therefore be driven by an explicit, version-controlled mapping table rather than by fuzzy string matching. Each entry binds a source pattern (file format, group path, channel name) to a canonical ID, and records the sign convention so that a channel measured positive-rearward is not silently treated as positive-forward.

Two failure modes deserve explicit handling. An unmapped channel means a required canonical ID has no source; the pipeline should quarantine the test and report which IDs are missing, because evaluating with a substituted default is worse than not evaluating. A duplicate mapping means two source channels claim the same canonical ID; this is always a hard failure, since the engine cannot know which one is correct. Both conditions should be surfaced in a machine-readable validation report alongside the parsed data.

Putting it together: a reproducible run

With the three stages in place, a run becomes deterministic: ingest the file set, synchronize to the trigger, apply the versioned mapping table, and only then invoke the evaluation engine. The observable verification criteria are straightforward. The ingestion report should list every channel with its unit and rate; the synchronization report should show per-channel offsets and any drift flags; the mapping report should show zero unmapped required IDs and zero duplicates. If all three reports are clean, the evaluation output can be trusted and stored against the test ID and rule version. If any report is not clean, the pipeline halts at the corresponding gate, and the operator receives a specific, actionable message rather than a silently degraded result.