H2-1 · What FDR/CVR is — scope, boundaries, and “what must never be lost”

A recorder becomes valuable only when its outputs remain trustworthy under the exact conditions that break ordinary logging: brownouts, abrupt power removal, internal resets, or media wear. This page focuses on the recorder’s internal chain (buffer → storage controller → NVMe/UFS → NAND → integrity → power-fail commit), and avoids deep dives into aircraft bus protocols, aircraft-wide power compliance, or full anti-tamper architectures.

Scope boundary: focus on recorder-internal reliability (write path, power-fail closure, integrity checks, readout proof). Do not expand into avionics network protocols, aircraft 28V front-end compliance, or full crypto/anti-tamper system design.

H2-2 · System architecture — from acquisition to crash-survivable memory

At a system level, the recorder sits between acquisition sources (flight-data aggregation and cockpit audio acquisition) and two consumers: maintenance offload and crash survivable readout. The design goal is not “maximum throughput,” but predictable persistence: the ability to state, test, and prove where “data is safely on media” under worst-case bursts and abrupt shutdown.

Each internal module should be described by its responsibility and its failure signature, so diagnosis stays inside the recorder boundary:

• Ingress: frames and paces sources; uncontrolled pacing creates burst-driven buffer overrun or timing skew.
• Input buffer: absorbs bursts; weak buffering shows up as missing segments, dropouts, or window discontinuities.
• Segment builder & metadata: converts streams into segments + index/manifest; a fragile index can make valid media content unreconstructable.
• Storage stack (NVMe/UFS): defines what “write complete” means; confusion here causes “acknowledged but not durable” records.
• NAND/FTL: wear, bad blocks, and write amplification; symptoms appear as rising ECC corrections, retries, or variable latency.
• Integrity checks: detects corruption at multiple layers; missing layers enable silent wrong data.
• Power-fail closure: freezes ingress, drains critical queues, and commits a last-consistent point; without this, recovery becomes guesswork.

This architecture view sets up later deep dives: NVMe vs UFS responsibility split (commit semantics), power-fail state machine (freeze/drain/commit), and integrity layering (CRC/ECC/hash + manifest).

H2-3 · Recording requirements that drive the design — bandwidth, retention, and worst-case bursts

A recorder rarely fails because its interface is “too slow” on average. It fails when short abnormal windows create bursts that overflow buffers, delay commits, or collide with flash management behavior. For CVR, continuous audio writes amplify this risk because flash housekeeping can create latency spikes and increase write amplification (WA). The goal is to turn “bandwidth and capacity” into a verifiable write budget that holds under stress.

Two practical consequences follow from these budgets:

• FDR burst protection: define the event window first (time-bounded burst), then size buffers and commit time so the window is never fragmented.
• CVR continuity protection: treat latency spikes as a first-class requirement (not a corner case); continuous writes + flash GC can cause dropouts unless buffered and committed deterministically.

H2-4 · NVMe vs UFS for recorders — what matters in power-fail and integrity

Both NVMe and UFS can support high write rates, but recorders care about commit semantics and recovery determinism. The most important questions are: (1) can the recorder force the storage stack to converge to a last-consistent point during a power-fail sequence, and (2) can metadata protection be tested and proven so corruption is detected rather than silent.

Later chapters should convert these gates into a concrete procedure: freeze ingress → drain queues → commit marker → verify manifest on next boot, then sample readback to confirm integrity across the reconstructed timeline.

H2-5 · Power-fail write — detection, hold-up, and “last-consistent-point” design

A power-fail event should not be treated as “try to write as much as possible.” The correct objective is convergence: freeze ingress, drain what can be made durable, commit a final marker that proves the LCP, and then power down. A recorder that cannot prove its LCP risks silent gaps, broken segment order, or a manifest that points to data that was never fully committed.

The “last-consistent point” is best implemented as a small, verifiable artifact on media: a commit marker (often tied to an epoch or monotonically increasing sequence) that is written only after the recorder has closed segment boundaries and updated the manifest/journal. If the marker is missing or invalid after restart, the recorder must fail closed (reject) and fall back to the previous valid epoch rather than guessing.

Verification hook (for later validation chapters): run a randomized power-cut matrix across normal and burst workloads and confirm every reboot can rebuild a monotonic timeline up to the latest valid commit marker.

H2-6 · Data integrity pipeline — CRC, ECC, journaling, and readback proof

A recorder’s integrity pipeline should be layered so each mechanism covers a different failure mode. Packet-level checks catch corruption introduced in transport or buffering, storage-level ECC handles media bit errors, and segment-level hashes protect reconstruction correctness across segments and manifests. Metadata consistency is maintained with journaling or double-write strategies so “data is valid but directory is broken” (or the reverse) cannot occur silently.

Metadata should be treated as safety-critical because it defines reconstruction. Journaling (or a two-copy scheme with versioning) should ensure that after any reset or power cut, the recorder selects the latest valid metadata set using a simple rule: choose the newest version that passes integrity checks. If no valid set exists, the system must fail closed and report a fault rather than producing plausible but incorrect readout.

H2-7 · Event triggers — acceleration triggers, continuous ring buffer, and pre/post windows

A recorder does not capture meaningful pre-crash context simply by “having an accelerometer trigger.” The practical guarantee comes from how the ring buffer is segmented, how often segments are committed to a consistent point, and how the trigger locks a window without fragmenting it. The pre-window must be more than “still in RAM” — it must remain reconstructable after power loss, with a manifest that can prove window completeness.

The ring buffer should be treated as a continuous, segmented timeline. Segmentation creates fast boundaries for freezing and committing: pre-window data is guaranteed only if it resides in segments that already belong to a known, valid commit epoch (LCP). When the trigger fires, the recorder latches the event and freezes a combined pre/post window, then commits the window’s manifest so readout can prove that the window is complete and in-order.

Practical linkage to power-fail closure: pre-window guarantees depend on commit cadence and segment boundaries, so the trigger pipeline must align with the LCP design.

H2-8 · Crash survivable memory unit — packaging, thermal, shock/vibration, connectors

The crash survivable memory unit (CSMU) concentrates the recorder’s most valuable asset: the final, reconstructable storage timeline. Survivability depends on structural layering and on the weakest interfaces — especially connectors and solder joints — as well as on thermal behavior under sustained write workloads. A robust design treats mechanical and thermal risks as integrity risks because degradation ultimately appears as ECC trend changes, read retries, and bad-block growth.

Packaging should be explained as a layered system: an outer enclosure and damping/insulation protect against impact energy, while internal stiffening supports the PCB and reduces local strain. Inside the thermal domain, the recorder should prioritize safe closure behaviors (commit markers and manifests) over raw throughput when approaching temperature limits, because the primary goal remains “readable and provable” storage after an event.

H2-9 · Health monitoring & built-in test — proving the recorder is still trustworthy

Maintenance decisions should not rely on a single “pass/fail” light. The objective is to combine built-in tests (BIT/BIST) with media-health telemetry so the recorder can answer three practical questions: Can it record now? Is risk rising? What action is required? A good health design is measurable: every critical signal is readable, loggable, and eligible for thresholds or trends.

Media-health indicators should be interpreted as a combination of irreversible degradation signals and trend-based early warnings. For example, a growing bad-block count is fundamentally different from an increasing ECC correction rate: one implies structural wear, while the other may indicate the recorder is “working harder” to maintain correctness. Thermal exposure history provides context: sustained high-temperature write workloads can accelerate error growth and increase retries.

Maintenance actions should be explicit and conservative. A recorder that cannot prove its write-path integrity or shows uncorrectable events should not be kept in service as “probably okay.” The safest policy is fail-closed: freeze, export what is provably valid, and replace the storage module when evidence indicates crossing a risk threshold.

H2-10 · Data offload & chain of custody — export, verify, and keep evidence consistent

Offload should be treated as a controlled recorder-side procedure, not an ad-hoc copy. The goal is to export a package that is complete, in-order, and provably consistent with the recorder’s commit epoch (LCP). This is achieved by entering a read-only export mode, building a manifest that enumerates segments, generating a verification chain, and recording an offload log that aligns with the exported segment IDs and epoch marker.

“Chain of custody” at recorder level is primarily about consistency: the export package, the manifest, and the offload log must describe the same segment set and the same commit epoch. If any gate fails — wrong boundaries, missing chunks, hash mismatch, or a log that does not align — the export should be treated as invalid and re-attempted from a known-good epoch.

H2-11 · Validation & production checklist — how to prove power-fail, integrity, and trigger logic

This checklist is written to be auditable. Each item includes a test condition, an observable artifact (log/counter/report), and a pass/fail rule. The structure is layered so engineering, production, and maintenance can each run a bounded set of tests without redefining correctness.

1) Engineering qualification (R&D validation)

R&D validation must cover worst cases, not averages. The matrix below focuses on the recorder’s internal choke points: input buffering, FTL commit, and the power-fail closure window. The objective is to show timing margin (early warning + hold-up) remains sufficient under the highest write pressure and the fastest rail collapse.

2) Production / EOL screening (fast, deterministic)

Production tests should be short and strict. Instead of running the full matrix, use a focused subset that is most likely to expose marginal hold-up timing, integrity mismatch, or a broken trigger chain. Production output must include a per-unit report snapshot.

3) Maintenance verification (periodic proof of trust)

Maintenance is about trend and proof, not exhaustive testing. The recorder should provide a lightweight write-path proof, plus a health snapshot that clearly maps to “Continue / Degrade / Replace.” If any verification gate fails, export should be treated as invalid until re-run from a known-good epoch.

Example validation BOM (specific part numbers)

The list below is a validation reference (examples) to anchor measurements and acceptance criteria. Final selection must match project temperature range, certification needs, and supply constraints.