Safety Lab Aero

ARP 4761A Safety Process

Assessment cockpits for the active project. Click any card for its inputs, activities, and completion state. Common Cause Analysis runs as a parallel track throughout.

Worklist

Items across the project that need attention. Click any row to jump to it.

Create isolated system folders below to manage subsystem functional hazard assessments and requirements.

Qualitative Severity Classifications

Applicable Quantitative Targets

Upper bounds per flight hour · design must show < target · DAL per ARP4754A.

Define n-state Markov chains for repairable subsystems with degraded modes, periodic maintenance, or multi-level redundancy. Mark each state as Working or Failed; provide pairwise transition rates. Steady-state probabilities solve πQ = 0 with Σπ = 1. Attach a model to a basic event via that event's config panel and the BDD / cutset / Monte-Carlo paths will all use Σπ(failed states) as P(event).

The default profile is your project baseline. Add a special mission profile (e.g. Long-haul) to analyse extended-exposure / latent-failure risk — same phases, different durations — then a fault tree picks which profile it's built for.

A Resource is a project-wide commodity — electrical/hydraulic/pneumatic power, fuel, mechanical drive, data/signal, thermal — that one or more systems PROVIDE and one or more aircraft functions CONSUME. Resources are not functions; they capture the provide/consume relationships that underpin shared-resource and common-cause reasoning.

A routing run is a physical path — wire harness, data bus, fuel/hydraulic/pneumatic line — that traverses one or more zones and carries one or more functions or items. Capturing routes makes common-route exposure visible (e.g. two "independent" channels sharing a zone or loom).

Items are the hardware / software units being certified — typically LRUs, computers, or CSCI/HWCI. Each item carries a DAL (FDAL or IDAL), an owning system (or aircraft-level), and a list of functions it realizes. Items are linkable from FTA basic events ("realized by") and FMEA piece-part rows, closing the Function → Item → Component traceability loop.

Every math engine in the tool is validated against textbook or regulatory-reference problems with known closed-form answers. Each benchmark is documented with its source citation, expected value, and tolerance. This page is the foundation of DO-330 tool qualification.

Unified view of every requirement in the project — Aircraft and per-system — organized into directories matching the certification deliverable structure. Pick a directory on the left to see its requirements on the right. Edits made here propagate to the underlying per-scope stores; the per-system requirement tabs continue to work as the in-context view.

Phase-by-phase progression of the active project against the ARP 4761A spine (AFHA → PASA → SFHA → PSSA → SSA → ASA) with Common Cause Analysis as a parallel track. Each card shows artifact counts, approval gates, and links into the relevant scoped view.

The standard requirements interchange format, imported with its identifiers, typed attributes, document hierarchy and trace relations intact. Two-step (preview, then signed import); re-import is idempotent — changed rows update, vanished rows are flagged, nothing is silently deleted.

Initiator → ordered barriers → every success/failure path enumerated with exact product arithmetic (Σp = 1, machine-checked). Severity calls are signed; outcomes linked to failure conditions are reconciled against the FHA classification — disagreement is a named finding (INV-27). Frequencies and barrier probabilities are your values.

Cameo owns the architecture; Safety Lab takes the safety projection: packages bind to systems (by name, then by signed alias), blocks arrive as item candidates. Two-step preview, signed apply, idempotent by XMI identifier — vanished elements are flagged, never deleted.

The referee of "everything connects": every id reference swept for resolution (DANGLING), every text-matched edge flagged for a proper id binding (FRAGILE), every artifact with no thread edge named (ORPHAN). Bindings are elicited acts stored in the project and themselves swept for staleness.

Validation, split from verification: is the requirement itself right, before asking whether it is met? Six deterministic correctness checks per requirement, completeness evaluated per SET, and attestation rigor scaled to the worst traced severity. A signature never overrides a failing check.

Project-wide view of every requirement's validation and verification posture (ARP 4754B §6.4 / §6.5). Filter by scope, level, type, and status to spot gaps before a stage gate.

The aircraft-level integration workspace (ARP4761A §3.3, Appendix B). The cockpit tracks inputs, completion criteria, and hand-off; the analyses live in the tabs beside it.

The whole-aircraft verification closure (ARP4761A §3.7, Appendix F): confirms every AFHA failure condition is closed by SSA evidence or aircraft-level analysis, with CCA confirmations and final FDAL/IDAL checks.

The capability floor per aircraft function and phase, at climbing fidelity: L0 — minimum-equipment survival rules ("MAC holds when ≥1 of {…} AND {…}"), compiled instantly to breach combinations and single-point findings; L1 — degraded states and modifiers; L2 — scalar floors from the SDD. Rules are engineering judgment until substantiated, so each is an assumption routed to the design organization. Unmodeled states default conservative: anything not shown to survive is presumed to breach.

ARP4761A B.3 / B.4.3.2 — the two PASA integration tables. The interdependence table marks which systems contribute to each aircraft failure condition (derived from function traces, resource provide/consume, and SFHA trace-backs; assert or clear the rest by hand — an empty cell means not yet reviewed, never "no"). Each FC's contributing-system set then becomes the column set of its Common Resource matrix below: rows are resource losses/malfunctions, cells the per-system effect, each row closing with the combined aircraft-level effect.

Every independence claim the safety case relies on, as one deduped record per member-set (ARP4761A §2.2, D.4.2.2). Auto-identified from minimal cut sets in Cat/Haz trees (probability credit) and DALgebra claims on AND/INHIBIT gates (DAL credit); CMA rows and generated requirements attach as evidence. A CCF contradiction or open CMA finding compromises every dependent gate, reduction, and requirement at once.

The Failure Modes and Effects Summary, derived live from the FMEA (ARP4761A §4.2, J.4.2). Rows group by (end effect, detection means) — the equivalence class at which a fault-tree basic event is defined — and each group's summed λ is what its linked basic event owes. Nothing here is hand-maintained; edit the FMEA and re-derive.

Early-stage reliability prediction: λ = Σ N·λg·πQ from the handbook's parts-count tables, every value carrying its citation. This is the predicted lane — the FRACAS ledger is the demonstrated lane, and the drift between them is shown, never hidden.

The as-built reliability picture: λ rollup from the verification trees and component library (prediction), dispatch reliability elicited from operations records, and the FRACAS field lane — observed MTBF against the model's prediction with chi-square confidence bounds.

The success-domain view. Derive the dual of any fault tree automatically — series where the tree ORs, parallel where it ANDs, k-oo-n dualized — or author with the DSL. Derived diagrams recompute from the live tree; they cannot drift.

Median-rank regression with suspension handling. β tells the regime: infant mortality, constant rate, or wear-out — and wear-out findings should reopen the constant-rate assumption in the safety model.

NHPP power-law MLE over test campaigns: is the fix program working? Instantaneous MTBF, growth rate, Cramér–von Mises fit check, and forward projection.

Series λ budgets by feasibility weight, Poisson spares protection levels, and chi-square demonstration test plans.

Worst-case vs RSS tolerance stacks with exceedance probability from the normal model, and applied-vs-rated stress audits against derating guidelines — the failure-physics margin before any statistics happen.

Every scheduled interval against its not-to-exceed bound from the live hazard model, with the inspection burden alongside — the safety↔maintenance trade on one screen.

λ-weighted detection coverage per system from the FMEA. Every undetected mode is latent-failure feedstock: detect it, failure-find it (MSG-3 OP/VC), or bound its exposure (CCMR).

Discard vs line vs shop on annual economics: demand × variable cost + amortized fixed capability cost.

Dispatch candidacy justified by the live safety model: an exact cut-set protection check, a quantitative dispatched-configuration evaluation through the engine, rectification categories converted to flight hours, and time-limited-dispatch exposure from a stated budget share.

Systems & powerplant logic: Maintenance Significant Items, functional-failure effect categorization (Level 1, categories 5–9), and task selection in the prescribed order (Level 2). Selected tasks push into the MTTR/MDT ledger; the τ bridge and golden thread take over from there.

The maintenance program joined to the safety model: tasks linked to LRUs and fault-tree events, MDT decomposition, demonstrated-vs-estimate verdicts, and the → τ bridge feeding inspection intervals into the CCMR latent sweep.

What the exact RBD engine cannot fold into a product form: standby redundancy with imperfect switching, warm dormancy, and missions whose success criterion changes by phase. Seeded runs — same seed, same model, same number — with binomial standard error and a 95% Wilson interval on every figure. Held against analytic standby solutions in the regression suite.

Telcordia-style and FIDES-style factor algebra (your licensed values, our arithmetic), duty-cycle composition of operating and storage rates, and accelerated-test planning via Arrhenius and inverse-power-law acceleration factors.

Goel–Okumoto and Jelinski–Moranda fitted by maximum likelihood on CSCI failure logs: residual fault estimates, current intensity, execution time to target. Informs test-progress decisions — certification credit for software remains development assurance at the assigned DAL.

Unintended paths, timing, indications and labels with nothing failed — outside FTA/FMEA by construction. Candidates are mined deterministically from the architecture model (multi-provider resources, bidirectional interfaces, loop-backs, deferrable configurations); each carries the question to answer and takes a signed disposition.

The λ and MTTR driving the safety case, priced: failures per year, repair labor, material, downtime, spares holding at 95% fill, NPV over the support period. Design trades price themselves because the numbers are the safety model’s own.

Program-level utilization and statistical policy in one place: annual FH, fleet size, FRACAS confidence level, duty-cycle and storage-ratio defaults. Every module keeps a safe default when a setting is absent.

The three programs beyond systems/powerplant: SSI ratings deriving deterministic task sets (metallic: corrosion + fatigue; composite: impact; safe-life: discard), zonal candidates derived from the ZSA register with the enhanced-zonal wiring test, and L/HIRF protection features whose intervals demand signed acceptance when they protect severe functions. All push into the one maintenance ledger.

The dependency graph the model already carries — resource provision, resource consumption, declared interfaces — compiled into one structure and cascaded. The audit-grade part: every cascade path is reconciled against the interdependence table. A path the table never reviewed is a finding; a path a cleared cell contradicts is a conflict.

Certification freezes an argument; service tests it. This is the watch list the safety case implies: severe conditions with the targets they staked, latents with the rates their inspections must validate, dispatch items with their TLD budgets, assumptions only service can validate, and FRACAS findings under statistical watch.

The blast radius before the change: declare the scope and a deterministic closure over the model graph names every failure condition, tree, requirement, common-cause row, principle and maintenance artifact the modification touches — and predicts which hand-offs will reopen. Closing a mod requires the reopened gates re-handed-off: the prediction grades itself.

The close-out discipline: every problem found in analysis, test, review or the field gets a signed lifecycle to closure — or a signed deferral with its rationale permanently visible. Open safety-related reports block the SSA gate.

Every development-assurance objective against live evidence: computed rows recompute from the model on every view, attestation rows are signed human acts. The audit-opening artifact, always current.

Audit readiness is not document storage — it is traceable evidence on demand. Generate the single artifact a DER or auditor takes away, assembled from the live model and carrying its own tamper evidence.

The program's methodology record (ARP4754B planning / ARP4761A §1.3): which method fills each objective slot, which checklist items were tailored out (signed, with rationale), and the depth-of-analysis defaults the certification basis drives. Gates check objectives; methods are this program's choice.

Every latent event in a Catastrophic/Hazardous tree (periodic-test τ or dormancy interval beyond one flight), with its computed not-to-exceed interval — the largest test/inspection interval at which the top event still meets its severity target (ARP4761A §5.1, E.3.2.4; AC 25-19A). Rows over their bound are candidate certification maintenance requirements.

Development Assurance Level mapping per DO-178C Table A-1 through A-7 (software) and DO-254 Appendix A (electronic hardware). The roll-up below shows what DAL is claimed across each system in the project — drill into a row to see which requirements / items contribute.

Per ARP 4754B Appendix A, each safety requirement should declare the certification credit it earns — the regulation, paragraph, method of compliance (analysis / test / demonstration / inspection / similarity), and status. The catalog below lists common 14 CFR Part 25 + CS-25 + AMC 25.1309 paragraphs; use the per-requirement "Manage MoC" button on the AC / Sys Requirements tabs to attach entries.

Compliance Status by Requirement

A baseline is an immutable snapshot of the entire project at a development milestone — typically PSSA at PDR, SSA at CDR, and at each certification submission. Each baseline carries a SHA-256 hash so any later tampering is detectable. Use baselines to establish what was reviewed / approved at each gate, then continue iterating in the live project.

The JARUS SORA v2.5 Specific-category thread, computed live from the operation: intrinsic Ground Risk Class → ground-risk mitigations → final GRC, Air Risk Class → SAIL, the SAIL’s Operational Safety Objectives with compliance, and containment. The engine owns every number.

The full traceability spine, laid out left to right: every aircraft function flows through its systems, failure conditions, fault trees, common-cause analyses (PRA / ZSA / CMA), safety requirements and verification. Pick a function to focus its thread, click any node to lay out its ecosystem, then generate its trace report. New here? Add a few failure conditions and fault trees first — every artifact you create links into this spine automatically.

Every assessment, requirement, and assumption can hold a threaded conversation. Open comments roll up here, organized by assessment type, so a reviewer can sweep through what still needs attention without hopping tabs.