Arc Skills / Reliability and maintainability
Review maintainability requirements
This task reviews maintainability requirements against the actual maintenance concept and repair boundary. Arc Skills returns clearer draft wording and verification questions without choosing an unapproved repair target.
Use this skill
Use Arc Skills to review these maintainability requirements for the named equipment and maintenance concept. Keep original IDs and wording alongside proposed revisions.
Inputs:
- Draft requirement and approved operational need.
- Technician, spare, access, tooling and safety assumptions.
- Repair procedure, clock boundary and demonstration plan.
Return missing definitions, effect on verification, proposed wording and decisions needed. Distinguish a single repair-time limit from MTTR, restoration probability and availability.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Original requirement | Preserves the intended target | Wording gap |
| Maintenance concept/resources | Defines credible repair conditions | Assumption list |
| Procedure and measurement plan | Defines start/stop and proof | Verifiable revision |
“Repair within 30 minutes” needs a clock and resources
Illustrative engineering example.
Synthetic requirement M-7 reads “Repair the controller within 30 minutes.” The maintenance concept expects a trained technician and a stocked replacement module at the equipment. Fault isolation, safe power removal and built-in test are part of the task, but travel to the site is excluded by the approved operational need.
| Original issue | Proposed M-7 wording or condition | Verification consequence |
|---|---|---|
| Clock start unclear | Start at technician arrival after fault indication | Record start event consistently; travel excluded by stated need |
| Repair task undefined | Include isolation, safe power removal, module swap and restoration | Procedure must exercise each included step |
| Clock stop unclear | Stop after successful built-in test and return-to-service checks | Time result cannot stop at physical replacement |
A bounded draft is: “With a trained technician, approved tools and a stocked replacement module at the equipment, the controller shall be restored within 30 minutes from technician arrival after fault indication to successful built-in test and return-to-service checks.” This preserves the supplied 30-minute limit and makes the task observable.
Whether one demonstration is enough depends on the approved metric and sample plan. A single run could show a specific repair completed within the limit, but it cannot by itself establish a mean or percentile. The resource assumptions belong in the maintenance concept and test setup; they should not be mistaken for design performance in every operating context.
Define exactly what the repair clock measures
- Identify the failed replaceable unit and the approved maintenance setting.
- Specify clock start, included tasks, safety steps and stop event.
- State personnel, spares, tooling and access conditions separately.
- Match the verification sample and statistic to the actual requirement metric.
Questions about this task
Is a 30-minute repair limit the same as MTTR?
No. A single task limit and the mean of a repair-time distribution answer different questions and need different evidence.
Should travel time count?
Use the approved operational need. In this example it is explicitly excluded, while isolation and return-to-service checks are included.
Sources and further reading
- NASA Reliability and Maintainability: NASA overview of reliability and maintainability practice and requirements.
- NASA Systems Engineering Handbook: Lifecycle, requirements, verification and technical-management guidance.