Event Recorder / Black Box for Rail Systems
← Back to: Rail Transit & Locomotive
Overview
This document provides a detailed guide on the functionality, validation, and verification of the Rail Event Recorder / Black Box, ensuring its data integrity, tamper detection, and compliance with industry standards in real-world railway conditions.
H2-1. Role & Evidence Grade: “Recording” vs “Evidentiary Record”
An event recorder becomes a black box only when its exports can support accident investigation, dispute resolution, and maintenance root-cause analysis with provable time correctness, tamper-evident integrity, and traceable custody. Storing “some data” is not sufficient; the system must prove that the record is complete, ordered, and unchanged.
System placement (what feeds it / what it produces):
- Inputs (evidence sources): speed/odometry, acceleration/IMU, discrete safety states (e-stop, brake apply, door inhibit), power events (UV/brownout), fault codes, and selected bus frames (Ethernet/serial/MVB/WTB/ECN as available).
- Recorder boundary: ingestion + timestamping + buffering + sealing + export; it must avoid “editing” semantics (no silent re-ordering, no loss without an explicit loss event).
- Outputs (evidence sinks): maintenance depot export package, optional backend upload, and regulator/third-party extraction packages with verification materials.
Four conditions of an evidentiary record (each must be checkable):
-
Traceable custody (chain-of-custody):
every export must produce an audit event: who exported, when, what range, and a cryptographic summary of the exported set.
Acceptance check: two exports of the same time range must generate distinct audit entries, both verifiable offline.
-
Verifiable integrity (tamper-evident):
data is segmented and bound to a signed manifest (hashes + metadata + index). Any byte-level modification must fail verification.
Acceptance check: modifying one segment must fail and pinpoint the corrupted segment ID.
-
Explainable context (why the record means what it means):
each sealed set must carry minimal context fields: time-quality state, sync source, power state, recorder health, trigger reason code, and loss indicators (drop/overrun).
Acceptance check: an investigator can reconstruct the event sequence without access to the full train control stack.
-
Reproducible time correctness (ordered causality with confidence level):
the timeline must include measurable sync quality (offset/holdover age/drift bound) and explicit time-step events (no silent time jumps).
Acceptance check: GNSS/PTP loss must change the recorded time-quality flags; time steps must be logged as events.
Common failure patterns (symptom → missing proof):
- Timeline mismatch: records exist, but event order cannot be trusted → missing time-quality flags and/or hardware timestamp placement evidence.
- “File exists” but cannot be trusted: exports can be edited → missing manifest binding + signatures + audit trail.
- Last seconds missing: the most critical tail is gone → holdup/flush/seal sequence not guaranteed and not logged.
- Export disputes: third-party doubts authenticity → missing chain-of-custody package (device identity, signed manifest, export audit record).
| Dimension | Ordinary Logging | Evidentiary Record (Black Box Grade) |
|---|---|---|
| Time | Best-effort timestamps, often software-based | Trusted time base + time-quality flags + explicit time-step events |
| Integrity | Files can be edited without detection | Segment hashes + signed manifest; any change is detectable |
| Power loss | Tail data frequently missing | Holdup + controlled sealing sequence + sealed-set marker |
| Export | Copy files | Export evidence package: data + manifest + signatures + identity + audit |
| Access control | Weak or operational-only | Role-based export, audited actions, keys protected by HSM/SE |
H2-2. Data Sources & Capture Boundary: What to Log, at What Fidelity
The practical goal is high evidence density within bounded storage and power budgets. This requires (1) a clear capture boundary, (2) a three-mode fidelity plan, and (3) trigger rules that produce sealed, audit-ready evidence sets rather than scattered files.
Signal taxonomy (by transport and evidentiary value):
- Continuous waveforms: acceleration (multi-axis), speed/odometry, selected power health channels (UV/brownout). These reconstruct dynamics and causality.
- Discrete events: brake apply/release, e-stop, door inhibit, watchdog reset, time-step events. These anchor the timeline and decisions.
- Bus messages: selected frames from Ethernet/serial/MVB/WTB/ECN. These provide command/diagnostic context when tightly filtered.
Three-mode fidelity plan (how capture scales when an event occurs):
- Mode 1 — Background: low-rate sampling or statistics (min/max/mean) + periodic health snapshots (time quality, power state, storage health).
- Mode 2 — Triggered window: high-rate capture for a bounded pre-trigger + post-trigger window (ring buffer → sealed evidence segment). Class-A signals escalate first.
- Mode 3 — Sealing: flush → write manifest → sign → mark sealed → record export/audit metadata. No silent overwrite of sealed segments.
Trigger taxonomy (each must emit a trigger reason code):
- Threshold triggers: shock/acceleration exceedance, speed delta-rate, UV/brownout edges, time sync loss.
- Composite triggers: emergency brake + speed above threshold; time sync loss + comms loss; repeated resets within a window.
- Commanded triggers: driver marker; TCMS/diagnostic tool marker. (Only the trigger mechanism is defined here.)
| Signal Type | Example Channels | Background Fidelity | Triggered Fidelity (Pre/Post) | Evidence Value | Storage Cost Driver |
|---|---|---|---|---|---|
| Continuous | Acceleration (XYZ), speed | Low-rate or stats snapshots | High-rate window (ring buffer → sealed segment) | Class A Causality | Sample rate × channel count × window length |
| Continuous | Power UV/brownout, temperature | Periodic health samples | Elevated rate during power events | Class B Explain | Event clustering + health cadence |
| Discrete | Brake apply, e-stop, door inhibit | Edge-only | Edge + debounce evidence + reason code | Class A Anchor | Event density |
| Bus frames | Selected diagnostic/command frames | Filtered subset | Expanded filter set within event window | Class B Context | Frame rate × filter breadth |
| Recorder meta | Time quality, storage health, sealing state | Periodic | High priority during event & sealing | Class A Proof | Low volume; critical for defensibility |
Practical acceptance criteria for H2-2: (1) every sealed set includes pre-trigger context, (2) every trigger has a reason code, (3) any loss/overrun is recorded as an explicit event, and (4) evidence packages remain verifiable offline.
H2-3. Time Correctness: GNSS/PTP/OCXO and a Trusted Time Base
In a rail event recorder, “time correctness” means more than a timestamp. A defensible timeline requires a trusted source, a verifiable distribution path, and detectable loss-of-lock—so every record carries enough evidence to prove the time quality at the moment of capture.
Time stack (primary → holdover → monotonic order):
- Primary sync sources: GNSS PTP (IEEE 1588) Provide alignment across devices when available; require explicit quality fields and source validity.
- Holdover: OCXO/TCXO Maintains continuity when GNSS/PTP is lost; must record holdover age and quality bounds to prevent “silent drift.”
- Monotonic ordering: Even without trustworthy absolute time, the recorder must preserve event order and relative intervals using a local monotonic counter with visible quality state.
Trusted time definition (must be auditable):
-
Trusted source: time originates from a known, authenticated source (GNSS receiver or PTP grandmaster domain) with validity status.
Required: source type, source ID/domain, validity flag, source quality level.
-
Verifiable distribution: timestamps are derived from a hardware-synchronized clock path (not a best-effort software clock).
Required: hardware timestamp enable state, clock domain ID, sync path status.
-
Detectable loss-of-lock: any lock loss, source switch, or time step is logged as an explicit event and reflected in time-quality flags.
Required: sync state, offset/jitter metrics, holdover age, time-step event entries.
| Field | What it proves | When to record | Typical pitfalls if missing |
|---|---|---|---|
| time_sync_state | Locked / holdover / free-run status at capture time | Background heartbeat + every sealed set | Investigators cannot trust ordering across devices |
| offset / path_delay | Alignment quality between local clock and reference | Periodic + higher rate during events | Cross-module alignment disputes cannot be resolved |
| ptp_servo_status | Servo convergence vs instability (jitter/oscillation) | Periodic + on state change | “Locked” is assumed even during unstable operation |
| gnss_fix_quality | Absolute time validity (fix class / quality indicator) | Periodic + on loss/reacquire | Time jumps appear as unexplained anomalies |
| holdover_age | How long the system has been drifting without a reference | Periodic during holdover | Silent drift is misinterpreted as true time |
| time_step_event | Explicit detection of time jumps and their cause codes | On every step / source switch | Event order becomes contestable after export |
Common failure patterns (symptom → first proof to check):
- Event order dispute: verify time_sync_state and offset/jitter around the incident window.
- Unexplained time jump: verify time_step_event and source switch cause codes.
- Tunnel segment mismatch: verify holdover_age growth and fix-quality transitions.
H2-4. Hardware Timestamping & a Deterministic Ingest Path
Time is only trustworthy when the timestamp is placed at the correct capture point. Software-layer timestamps can be distorted by queueing, interrupt latency, and scheduler jitter. A rail-grade recorder therefore treats timestamp placement as an auditable design decision with explicit downgrade flags.
Timestamp trust ladder (highest → lowest):
- PHY/MAC hardware timestamp: best for Ethernet/PTP frames; minimal software distortion.
- FPGA / hardware latch: best for discrete edges and synchronized sampling triggers.
- MCU peripheral capture: acceptable when ISR latency is bounded and measured.
- Driver/software timestamp: downgrade mode only; must set explicit “software timestamp” flags.
| Dimension | Hardware Timestamp | Software Timestamp |
|---|---|---|
| Placement | Near frame/edge boundary (PHY/MAC, latch, capture) | After queueing (driver stack / user space) |
| Main error sources | Clock discipline error, hardware path delay | Queue depth, ISR latency, scheduling jitter, buffering |
| Cross-device alignment | Strong; supports causality chains | Weak; disputed ordering is common under load |
| Recorder proof fields | hw_ts_enabled, clock_domain_id, ptp_ts_counter | sw_ts_mode, queue_delay_peak, isr_latency_peak |
| Required flags | time-quality + hw placement identity | explicit downgrade event + sw timestamp mode flag |
Multi-source alignment (unified time axis across domains):
- Unify clock domains: map ADC/IMU sampling, discrete edges, and network frames to a single disciplined clock via capture/latch points.
- Budget alignment error: track worst-case queue/ISR delay metrics so alignment quality is defensible.
- Detect alignment degradation: record alignment-quality indicators during congestion or time-source changes (no silent degradation).
- Do: keep Ethernet/PTP timestamps at PHY/MAC when available and record hw timestamp enable state.
- Do: latch discrete events with hardware capture and record debounce/capture configuration IDs.
- Do: log explicit events for “timestamp mode changes” and “time step” with cause codes.
- Don’t: treat software timestamps as event-time without marking downgrade state.
- Don’t: apply silent time corrections (step/slew) without recording them as explicit events.
H2-5. Storage Architecture: NVMe, Wear, WORM, and Crash-Consistent Layout
A rail black box fails most often for storage reasons: power loss during writes, crash-inconsistent indexes, and wear-driven unreadable data. Evidence-grade storage therefore treats the “record” as a sealed unit (segments + manifest) rather than a conventional file that can be silently edited.
Why NVMe is a fit (and what must be controlled):
- Strengths: High throughput Parallel queues Low-latency flush Supports triggered high-fidelity windows and concurrent metadata writes.
- Risks: Thermal throttling Power-loss consistency Write amplification These must be captured as recorder-visible health signals to keep exports defensible.
Crash-consistent layout (append-only → segment → manifest):
- Segment: the smallest evidence block containing samples/frames/events for a bounded time window, with segment ID and a segment hash (or chunk hashes).
- Manifest: an index listing segment IDs, hashes, time range, trigger reason code, time-quality summary, and storage-health summary; this is the object that gets signed.
- Append-only rule: no in-place mutation for evidence data; new versions are appended, and state transitions are logged as explicit events.
| WORM Strategy | How it prevents tampering | What must still be logged | Typical trade-offs |
|---|---|---|---|
| Physical WORM | Media-level write-once behavior | Export audit + time-quality evidence | Higher cost, operational complexity |
| Logical WORM | Append-only segments + hash chain + signed manifest + non-rollback index | Seal markers, index versioning events, tamper events | Requires careful crash recovery design |
Wear & health management (evidence readability over years):
- Endurance: TBW / “percentage used” trends should drive proactive maintenance before evidence becomes unreadable.
- SMART/health logs: media errors, reallocated blocks, unsafe shutdown count, temperature throttling events.
- Bad block growth: growth rate is more informative than a single snapshot; record it as a health signal.
- Scrub: periodic read/verify to detect latent errors; scrub results should appear as verifiable maintenance events.
H2-6. Hold-up & Power-Loss Protection: Supercap/PLP and Tail Integrity
The most contested evidence often lies in the last seconds around a power disturbance. Hold-up protection therefore targets a strict outcome: within the available energy window, the recorder must preserve tail data, complete sealing (manifest + signature + marker), and power down cleanly with explicit state evidence.
Architecture (energy chain + detection chain + policy chain):
- Energy chain: wide-VIN input → charge/limit → hold-up store (supercap / battery / PLP) → critical rails (controller, NVMe, HSM/SE).
- Detection chain: brownout / power-fail detection must be fast and logged with a timestamp and stage code.
- Policy chain: staged shutdown: freeze nonessential writes → emergency write lane → seal → power off.
Emergency write lane (keep sealing predictable under power-fail):
- Allowed writes: tail data buffer flush, manifest, signature, seal marker, and a minimal audit entry.
- Blocked writes: background statistics, compaction, noncritical maintenance logs, best-effort uploads.
- Write amplification control: avoid in-place metadata updates; keep writes aligned and bounded to complete within the hold-up window.
| State | Entry condition | Must-complete actions | If time expires |
|---|---|---|---|
| PowerFail | VIN drop / UV edge / power-fail comparator | Freeze noncritical writes; record stage + timestamp | Record power-fail escalation event on next boot |
| Flush | PowerFail latched | Flush tail buffers; finalize segment hashes | Emit seal_failed:flush |
| Seal | Flush completed | Write manifest; sign with HSM/SE; write seal marker | Emit seal_failed:sign or seal_failed:marker |
| PowerOff | Seal marker confirmed | Orderly power down; preserve last state snapshot | If forced-off, log “unsafe shutdown” count and recovery result |
H2-7. Integrity & Chain-of-Custody: Hashes, Signing, and an Audit Trail
Evidence-grade recording assumes attempts to modify, delete, splice, or reorder data. The core requirement is tamper-evidence: any change must break a verifiable chain (hashes + signatures), and any access or export must be traceable through a signed audit trail.
Integrity chain (three layers, each answers a different question):
- Chunk hash: pinpoints which block changed (supports fast localization and media-error diagnosis).
- Segment hash: protects the evidence window boundary (prevents silent truncation or local replacement).
- Manifest hash: protects the global set (segment list, order, time range, trigger codes, time quality, health summary).
| Tamper attempt | First expected failure | What it proves | Minimum evidence fields |
|---|---|---|---|
| Delete a few seconds (cut) | Manifest time range / segment sequence mismatch | Record set boundary cannot be silently altered | segment list + time range + seal marker |
| Replace one segment | Segment hash or manifest hash mismatch | Local substitution becomes detectable | segment hash + manifest hash |
| Reorder segments | Chain/sequence validation fails | Causality ordering is protected | segment sequence + chain hash |
| Splice two incidents | Manifest signature does not validate | Only device-signed sealed sets verify | signature + public verification material |
Digital signing (device identity binds the record set):
- What is signed: the manifest (not every sample), because the manifest already binds all segment hashes and critical metadata.
- What export includes: the signature plus verification material (certificate chain or public key material) so third parties can validate independently.
- What must be explicit: any key epoch/version used for signing should be recorded in the manifest and audit events.
Minimum audit fields for evidence export:
- export_actor (role / operator ID) and auth_context (privilege level)
- export_time with time quality summary (sync state + offset snapshot)
- export_scope (event ID / window / segment range)
- export_digest (hash of exported package)
- export_medium_id (media/port identifier, or equivalent traceable label)
H2-8. Encryption at Rest & Key Management: HSM/SE, Provisioning, Rotation
Black box encryption must be compatible with sealing and third-party verification. A practical approach is segment encryption for payload confidentiality while keeping the manifest plaintext but signed for fast indexing and independent integrity checks. Keys must be managed as a lifecycle (provision → rotate → revoke), not a one-time setup.
Encryption scope choices (what matters for a recorder):
- Full-disk encryption: broad coverage but can complicate recovery and scope discovery during investigation workflows.
- File-level encryption: fine-grained but metadata consistency can still be fragile under power loss.
- Segment encryption (preferred): predictable sealing, minimal decrypt surface, and compatible with signed manifest indexing.
HSM/SE responsibilities (keys never leave the chip):
- Device identity: holds the signing keypair and enforces identity-based attestation.
- Key wrapping: protects encryption keys (KEK/DEK hierarchy) without exposing raw keys.
- Anti-rollback: monotonic counters or secure versioning prevent reverting to older keys/firmware states.
- Audit support: key-epoch/version is stamped into manifests and audit events to keep verification deterministic.
| Lifecycle step | Recorder-relevant actions | Minimum recorded fields | Why it matters for evidence |
|---|---|---|---|
| Provision | Inject device identity material and initial policy/epoch; bind to manufacturing batch | cert serial, policy version, key epoch, device ID | Proof of origin and reproducible verification baseline |
| Rotate | Introduce new epoch; keep verification compatibility for older sealed sets | epoch change event, activation time, overlap window | Prevents long-term key risk without breaking past evidence |
| Revoke | Mark identity/epoch as untrusted; prevent acceptance as a trusted source | revocation list version, status code, update time | Limits damage if device is lost or compromised |
H2-9. Tamper Detection & Anti-Rollback: Physical + Logical Evidence
A rail black box should be able to prove it was not silently altered. The practical requirement is tamper-evidence: physical anomalies and logical rollback attempts must generate high-priority events that are sealed and signed, so deletion or editing attempts become detectable.
Physical tamper signals (feasible sensing + recordable evidence):
- Enclosure open: tamper switch state, first-trigger timestamp, duration, and count.
- Thermal anomaly: internal temperature peaks, time-above-limit, NVMe thermal throttle count.
- Power anomaly: VIN min/max, UV/OV counts, power-fail triggers, unsafe shutdown count.
- Probe/debug exposure: debug-port state, abnormal reset reason codes, clock fault counters (where supported).
Logical tamper attempts (rollback surfaces that must be detectable):
- Firmware rollback: older images can weaken recording policy; prevent or record rollback attempts with stage-coded events.
- Time rollback/jump: record time-quality drops and timestamp jumps (magnitude + sync state snapshot).
- Delete/edit attempts: append-only structure must make deletion visible (missing segments, chain breaks); access attempts should create audit events.
| Tamper class | Typical trigger | Minimum event fields | Sealing requirement |
|---|---|---|---|
| Physical | open / temp / power / debug anomalies | type, timestamp, duration, counters, snapshot (VIN/temp/state) | Write to tamper segment and include in signed manifest summary |
| Firmware | rollback attempt, boot measurement mismatch | current version, requested version, boot result code, policy epoch | Non-rollback counter enforced by HSM/SE; event must be signed |
| Time | time jump, sync loss, offset spike | jump magnitude, sync state, holdover age, offset snapshot | Time anomaly must be sealed to preserve causality claims |
| Access | unauthorized export, repeated auth failures | actor/role, interface, scope, failure codes, export digest (if any) | Audit entries should be integrity-protected and signed |
H2-10. Interfaces & Export Workflow: Service Tool, Depot, Regulator Extraction
Evidence is only useful if it can be extracted and independently verified. Export design should support three operational tiers—service, depot, and regulator—while ensuring least privilege, self-contained verification materials, and a signed audit trail for every export.
Acquisition interfaces (choose per tier and policy):
- Ethernet: high throughput; supports depot bulk extraction and integrity checks.
- Serial / maintenance bus: robust fallback; supports minimal scope exports and health snapshots.
- USB or dedicated service port (if allowed): controlled extraction to approved media; must log medium ID.
- Dedicated maintenance connector: preferred for access control and environmental hardening.
Export package (minimum required contents):
| Item | What it contains | Why it is required |
|---|---|---|
| Data segments | sealed segment payloads for the selected scope | primary evidence content |
| Manifest | segment list, hashes, order, time range, trigger codes, time-quality summary | binds the sealed set for verification |
| Signature | device signature over the manifest | proves origin and prevents silent modification |
| Verification material | certificate chain or public key material | enables independent offline validation |
| Time quality report | sync state, offset snapshots, holdover age, relevant time flags | supports causality claims across devices |
| Device identity summary | device ID, firmware/policy epoch summary, key epoch/version | ensures deterministic verification context |
| Export audit entry | actor/role, interface, scope, export digest, medium ID, export time | chain-of-custody traceability |
Offline verification steps (tool-agnostic):
- 1) Package sanity: validate required files and structure; confirm scope identifiers.
- 2) Signature verify: validate manifest signature using the included verification material.
- 3) Hash verify: recompute segment/chunk hashes and match manifest values; detect missing or reordered segments.
- 4) Time coherence: check time-quality fields, monotonic sequence constraints, and timestamp jump markers.
- 5) Custody verify: validate export audit entry (actor/time/scope/digest/medium ID) and its integrity protection.
- 6) Report: output PASS/FAIL, failure stage, and the first mismatch location.
H2-11. Validation & Field Feedback Loop: Prove It Under Rail Conditions
The validation loop must demonstrate that the recorder remains resilient under real-world railway conditions. This chapter focuses on feedback-driven validation, covering bench tests, EMC tests, and field simulations. It highlights how repeated tests under varying conditions ensure consistent evidence integrity.
Bench validation (test matrix for worst-case scenarios):
- Power failure testing: Different phases, loads, temperature cycling, storage states.
- Time jump & lock loss injections: Simulate synchronization issues with GNSS/PTP and inject offset jumps.
- Full disk & wear tests: Test recorder stability with near-full storage and high-write cycles.
- Temperature cycling: Test impact of temperature changes on performance and data consistency.
| Test Condition | Test Scenario | Expected Result |
|---|---|---|
| Power Failure | Different phases (write, seal, sign), load types, full disk, temp stress | Data loss < 5%, last N seconds guaranteed to be written, manifest remains intact |
| Time Jump | Simulate GNSS/PTP lock loss, time offset spikes | Time quality must degrade, event integrity must remain intact |
| Full Disk/Write Amplification | Stress-write on storage, nearing full disk | Write amplification must be minimal, segments should remain consistent |
| Temperature Cycling | Temperature fluctuations, NVMe throttling | Temperature anomalies must trigger events, no data loss during cycles |
EMC & Transients: Recorder I/O & Power Disruption Resistance
- Power transients: Protect against power dips, spikes, and surges.
- I/O interference: Test Ethernet, serial, and maintenance bus resistance to noise.
- Time distribution immunity: Validate time coherence when subjected to signal noise or interference.
Field Validation: Simulated Incident & Maintenance Practice
- Incident/Alarm Simulation: Simulate faults, alarms, and trigger conditions to verify event logging.
- Export Link Simulation: Test export validity under various field conditions, ensuring data integrity.
- Maintenance Operator Drills: Simulate common operator errors and verify evidence traceability.
Validation Feedback Loop: Iterative Improvements Based on Field Data
- Critical metrics to track: Power failure count, time quality degradation, disk health, export success rates.
- Iterative tuning: Adjust recording thresholds, write strategies, and time synchronization based on validation feedback.
- Update cycles: Incorporate real-world findings to continuously enhance recorder reliability and evidence integrity.
Request a Quote
FAQs
Below are frequently asked questions (FAQ) related to the Rail Event Recorder / Black Box, along with answers that map back to the corresponding chapters, providing a clear link to the evidence fields and strategies behind each answer.
Answer: This issue is likely caused by either a PTP lock loss or a local time base drift. You should verify the time sync state, offset, and holdover age to pinpoint the cause.
Evidence Fields: Time sync state, offset, holdover age, PTP servo status.
Action Strategy: Compare GNSS/PTP time base with local time base and check for time quality degradation markers.
Answer: If the manifest verification fails, it might be due to either an unsealed manifest or a key chain change. Check the certificate chain and verify the key version handling.
Evidence Fields: Manifest hash, signature, public key material.
Action Strategy: Check if the export signature matches the public key and if the key version was updated or mismanaged.
Answer: Missing last 10 seconds after a power loss might be due to insufficient holdup capacity or improper flush strategy. Check the flush time and holdup duration to ensure it’s adequate.
Evidence Fields: Flush time, holdup duration, powerfail count.
Action Strategy: If the flush strategy is incorrect, it can cause write amplification, leading to the loss of the last few seconds of data.
Answer: Occasional read-only or disk drop may be caused by temperature issues, power transients, or wear-out. The SMART fields to check are temperature, voltage, TBW (Total Bytes Written), and bad block count.
Evidence Fields: SMART log, temperature, supply voltage, TBW (Total Bytes Written).
Action Strategy: If the issue is temperature-related, check the thermal throttling logs. If it’s wear-out, monitor the SMART bad block count and TBW.
Answer: If the exported evidence is questioned, the missing component is likely the chain-of-custody information, which includes the actor, export time, export medium ID, and export digest.
Evidence Fields: Export actor, export time, export digest, export medium ID.
Action Strategy: Ensure that all export events are logged and include the necessary chain-of-custody fields to verify authenticity.
Answer: Time jumps when entering a tunnel may indicate a holdover strategy failure or that time quality flags were not recorded correctly. Verify the time quality and GNSS fix quality fields.
Evidence Fields: Time quality, holdover age, GNSS fix quality.
Action Strategy: Ensure that time quality flags are recorded correctly during holdover periods and that holdover duration is properly tracked.
Answer: The data misalignment may be caused by not using hardware time-stamping or due to software queue jitter. Verify whether hardware time stamps were used correctly.
Evidence Fields: Time offset, time sync, hardware timestamping.
Action Strategy: Ensure that hardware time stamps are used to align multi-source data and that the software queue jitter does not affect the data flow.
Answer: Slow export after encryption might be caused by full disk encryption or poor manifest/index design. The best practice is to encrypt data segments and keep the manifest in plaintext.
Evidence Fields: Encryption method, manifest design, data segment size.
Action Strategy: Ensure that data segments are encrypted while the manifest remains unencrypted for fast indexing, and optimize encryption algorithms to avoid performance hits.
Answer: If tampering is suspected, you should verify tamper detection events, including enclosure open events, temperature anomalies, and debug access attempts.
Evidence Fields: Tamper events, tamper_open, tamper_close, tamper_temperature.
Action Strategy: Check for physical tamper detection events and ensure they are signed and sealed for evidence integrity.
Answer: After a firmware upgrade, data may fail verification due to incorrect certificate rotation or improper handling of version counters. Ensure that the version counters and certificate chain are properly updated and maintained.
Evidence Fields: Device identity, version counter, certificate epoch, firmware version.
Action Strategy: Ensure that version counters are incremented correctly and the certificate chain is updated during firmware upgrades.
Answer: Overflow in recording capacity may be caused by overly aggressive sampling or improperly sized trigger windows. Adjust the sampling rate and ensure that the trigger window is properly limited.
Evidence Fields: Sampling rate, trigger window, data size.
Action Strategy: Reduce sampling frequency or size the trigger window to control the data flow and prevent overflow.
Answer: If the cause cannot be determined from the logs, you may lack essential context signals or time quality fields. Ensure all context signals are recorded and time coherence is maintained.
Evidence Fields: Context signals, time quality, event sequence.
Action Strategy: Ensure that all relevant context signals and time quality markers are recorded to preserve causality.
