Arc Skills / Architecture and engineering budgets
Review single points of failure in an architecture
Redundancy is meaningful only when alternate paths remain available after the chosen failure. Arc Skills takes a dependency diagram and loss criterion and returns candidate single points plus evidence needed to credit backups.
Use this skill
Use Arc Skills to screen my architecture for candidate single points of failure.
Inputs:
- Precisely stated loss condition and operating mode
- Dependency diagram for all claimed successful paths and shared resources
- Failure assumptions, backup configuration, switching and test evidence
Return a dependency table showing what remains after each credible single failure, candidate common points and evidence needed to credit alternates. Do not infer independence from duplicate boxes alone.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Loss criterion | Defines what success must survive | Top event for backward trace |
| Dependency architecture | Reveals common sources and shared controls | Path-by-path failure screen |
| Backup evidence | Determines whether alternate service is credible | Open proof and bounded conclusion |
Two computers share one converter
Illustrative engineering example.
This illustrative architecture has two flight computers but powers both from the same DC converter. A claimed emergency converter is mentioned in a sketch without a switching description or test record. The criterion is loss of all flight computation under one failure.
Main bus → shared converter → computer A
└→ computer B
Emergency converter → switch? → computers (path not established)
Loss condition: both computers unavailable in flight mode| Dependency / failure | Path A | Path B | Conclusion |
|---|---|---|---|
| Computer A internal fault | Lost | Potentially available; shared software not assessed | Not a single point for this hardware fault alone |
| Computer B internal fault | Potentially available; shared software not assessed | Lost | Not a single point for this hardware fault alone |
| Shared converter fails | Lost | Lost | Candidate single point for computation |
| Emergency converter called upon | Switching path unknown | Load support unknown | Cannot credit until configuration and test evidence exist |
The two processor boxes provide a potential second path for an individual computer hardware fault, yet both paths terminate at one converter. Under the explicit converter-failure assumption, that common node can remove both computers. It is therefore a candidate single point relative to the stated loss criterion, without assigning a failure probability or safety class.
To close it, identify the emergency converter’s electrical independence, switching trigger, transfer behavior and load capacity in flight mode, then inspect a representative test. Separate common software faults and shared command inputs remain additional questions; adding an emergency power label on a diagram does not answer them.
Trace each success path backward
- Define the exact loss of function and operating mode.
- Trace power, sensing, processing, command and actuation dependencies for each claimed path.
- Apply one credible failure at a time and see whether every success path disappears.
- Credit a backup only with evidence of independence, transfer and capacity under the same condition.
Questions about this task
Does a candidate single point mean the design is unacceptable?
Not by itself. It identifies a dependence for the approved hazard and reliability process to assess.
Do two computers always provide redundancy?
Only for failure modes where their supporting power, inputs, software and outputs remain sufficiently independent.
Sources and further reading
- NASA Systems Engineering Handbook: system design processes: Stakeholder expectations, logical decomposition, functional allocation and design decisions.
- NASA Systems Engineering Handbook: product realization: Interface definition, integration sequence and verification context.