Arc Skills / Reliability and maintainability
Review a reliability block diagram
This task tests a reliability block diagram against the system’s actual mission success logic. Arc Skills returns a marked-up path review that exposes omitted common elements and unsupported parallel credit.
Use this skill
Use Arc Skills to review this RBD for the defined mission-success event. Trace each drawn path through the actual architecture, power and failover behavior.
Inputs:
- RBD, mission interval and success definition.
- Architecture, shared resources and switching/voter logic.
- Data boundaries for each block.
Return diagram-element findings, corrected qualitative logic and data questions. Do not apply independent-parallel arithmetic until every branch can deliver success and dependence is justified.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| RBD and success criterion | Defines drawn success paths | Logic review |
| Architecture and power/data paths | Finds missing series elements | Proposed correction |
| Failover and data records | Tests parallel-path independence | Calculation limitation |
Parallel computers still depend on one converter and voter
Illustrative engineering example.
A synthetic RBD shows computer A in parallel with computer B for a one-mission command function. The actual design routes both through converter P-1 and a single output voter V-1. Either computer can compute a valid command, but V-1 must select and deliver it.
Drawn: A OR B
Architecture: P-1 AND (A OR B) AND V-1| Element/path | Drawn claim | Architecture evidence | Correction |
|---|---|---|---|
| A ∥ B | Either computer succeeds | Each can compute the command | Keep parallel only for intrinsic computer behavior |
| P-1 | Omitted | Both computers require one converter | Place one P-1 block in series |
| V-1 | Omitted | Single voter selects/delivers output | Place V-1 in series; inspect failover coverage |
The corrected Boolean success statement is P-1 succeeds AND (A succeeds OR B succeeds) AND V-1 succeeds. A model that includes only A ∥ B would overstate success if P-1 or V-1 can fail.
The table does not calculate a probability because the converter, voter and channel data are absent, and the channels may have common causes. The voter may also have detection and switching limitations; those need explicit evidence before crediting every computer path. Review block boundaries so board-level and component-level rates are not mixed or double counted.
Trace a valid command from input to output
- Define mission success, phases and whether repair is allowed.
- For each parallel branch, ask whether it alone can meet the success condition.
- Add required common power, sensing, voting, output and switch elements once.
- Match every block with its failure-data boundary and dependence assumption.
Questions about this task
Where does a shared converter go?
In series with the parallel computer pair when its success is required for both paths.
Does a parallel drawing prove redundancy credit?
No. Switching, common resources and common-cause behavior determine whether both drawn branches are truly usable.
Sources and further reading
- NASA Fault Tree Handbook with Aerospace Applications: NASA-hosted guidance for fault-tree gates, cut sets and reliability block diagrams.