Arc Skills / Safety
Perform a failure modes and effects analysis
This task builds an FMEA at a stated architecture level and configuration. Arc Skills returns failure-mode rows that separate a fault, local effect and possible system consequence without inventing severity or rates.
Use this skill
Use Arc Skills to perform an FMEA for the supplied item/function boundary and operating modes. Trace each credible failure behavior forward through the next-level function to the end effect.
Inputs:
- Architecture, interfaces, modes and configuration.
- Detection, voting, annunciation and recovery design.
- Existing hazards, requirements and project severity criteria if any.
Return rows with mode, local effect, system effect, detection, recovery, source and unresolved design question. Do not assign a normative RPN or likelihood without the project scheme and data.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Functional breakdown and mode | Sets analysis level and phase | Analyzed element list |
| Failure behavior and interfaces | Supports effect propagation | FMEA rows |
| Diagnostic/voter evidence | Constrains end effect and recovery | Open design questions |
A plausible-value sensor freeze is not an open circuit
Illustrative engineering example.
In this synthetic pressure-control system, sensor S-1 feeds the Controller in regulation mode. Architecture sketch ARCH-P rev A identifies the path; diagnostic note DIAG-P rev A states that an open circuit is annunciated. Neither source defines recovery, voting or stale-data logic.
| Operating / failure mode | Local effect | Next/system effect | Detection | Recovery | Source / open question |
|---|---|---|---|---|---|
| Regulation / S-1 open circuit | No valid measurement | Controller loses one input; final control effect depends on voter | Annunciation stated; latency and test evidence absent | Not defined in supplied design | ARCH-P A; DIAG-P A. Obtain voter and recovery logic. |
| Regulation / S-1 plausible-value freeze | Repeated old but apparently valid pressure sample | Potential misleading control input; end effect unresolved | No stale-data check supplied | Not defined in supplied design | ARCH-P A; candidate from repeated-sample behavior. Obtain freshness logic and fault response. |
| Regulation / S-1 slow drift | Biased measurement within plausible range | Could bias control or indication if unchecked | Calibration and diagnostic bounds absent | Not defined in supplied design | ARCH-P A; drift is a candidate to confirm from sensor evidence. Obtain error bounds and control behavior. |
These are distinct failure behaviors even though all concern one sensor. Open-circuit detection cannot be credited for a frozen value without evidence that the same logic sees it. The local effect is known from the hypothetical mode; the system effect is intentionally conditional on the undocumented voter.
No severity, probability or risk-priority number appears because the project criteria and failure data were not provided. The engineer can use the row to request design logic and tests, then propagate each mode through the actual architecture and connect it to a hazard if warranted.
Trace effects at named levels
- Fix the analyzed item, version, function and operating modes.
- Select credible modes from actual interfaces and behavior, not a universal checklist.
- Write local, next-level and end effects separately; mark unknown propagation.
- Add diagnostic latency, recovery and source evidence before any project-specific ranking.
Questions about this task
Why not infer the end effect from the sensor mode?
Voting, annunciation and fallback behavior may prevent or change propagation. Name those missing mechanisms instead of guessing the final consequence.
Should every row receive an RPN?
Only if the project explicitly uses a defined scheme for that purpose. Ordinal codes should not be presented as physical risk probabilities.
Sources and further reading
- NASA Software Engineering Handbook: FMEA: Describes function, failure mode and effect reasoning.
- NASA Systems Engineering Handbook: Lifecycle, requirements, verification and technical-management guidance.