Arc Skills / Safety
Assess common-cause failures between redundant systems
This task tests a redundancy claim against dependencies that can affect both channels. Arc Skills produces a mechanism-by-mechanism map of shared resources, common software lineage and evidence needed before independence credit is taken.
Use this skill
Use Arc Skills to assess common-cause exposure in the named redundant architecture and mission interval. Map every channel through power, sensors, data, software, environment and maintenance.
Inputs:
- Channel architecture and current configuration.
- Shared-resource, installation and software-lineage records.
- Existing fault tree, FMEA and independence claim.
Return a dependency table naming the common mechanism, both affected paths, current control, supporting evidence and unresolved test. Do not assign a beta factor or independent-channel probability without project data.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Channel paths | Defines the exact credited redundancy | Dependency map |
| Power/firmware/installation records | Reveals simultaneous failure mechanisms | Common-cause candidates |
| Control and test evidence | Shows whether separation is implemented | Conditional independence finding |
Two processors still share power and firmware lineage
Illustrative engineering example.
A synthetic control unit has processors A and B on separate boards. Both boards receive DC from converter P-1 and run builds compiled from the same firmware source. The safety case treats processor hardware failures as independent but does not address these shared inputs.
| Shared element | Failure mechanism | Current evidence | Consequence for claim |
|---|---|---|---|
| Converter P-1 | One converter loss removes power from both channels | Schematic shows a single feed | Represent P-1 as a common series element |
| Firmware source F-2 | A shared requirements or algorithm defect can command both channels wrongly | Both binaries derive from F-2 | Diversity or verification argument needed; separate boards do not resolve it |
| Board hardware | Intrinsic board failure may affect only one path | Separate boards shown; installation details absent | Independence remains conditional on environment and interfaces |
Power loss and common firmware defects are different mechanisms. A second converter could address the first, but would not break the shared software lineage. Conversely, design diversity could address some software commonality while leaving P-1 untouched.
The table makes no frequency claim. It shows why multiplying two channel reliabilities as independent would omit a single-point P-1 failure and possibly correlated firmware behavior. The next decision is which independence credit the project actually needs, followed by physical and verification evidence for the selected controls.
Probe one dependency class at a time
- Draw complete channel paths, including failover, supplies, sensors and output stages.
- Identify resources, locations, development inputs and maintenance actions shared by both.
- For each mechanism, test whether the proposed separation interrupts it.
- Carry unresolved common-cause paths into the fault tree and safety argument.
Questions about this task
Are separate processors independent channels?
Only for failure mechanisms genuinely isolated by the architecture. Shared power, inputs, environment or software can defeat both.
When can common-cause probability be quantified?
When the project supplies a defensible event model, exposure basis and data. This review first identifies mechanisms and evidence gaps.
Sources and further reading
- NASA Fault Tree Handbook with Aerospace Applications: NASA-hosted guidance for fault-tree gates, cut sets and reliability block diagrams.