Arc Skills / Interfaces
Plan system integration order
An integration order is useful when each added element can be checked before another is introduced. Arc Skills takes dependencies and available equipment and returns a conditional step plan with evidence limits.
Use this skill
Use Arc Skills to plan the integration order for my subsystems.
Inputs:
- Dependency and Interface map, component readiness and exact configurations
- Test equipment, simulators, handling constraints and available observations
- Provisional acceptance checks and release-gate owners
Return an ordered table with prerequisite, added connection, check, stop condition, evidence and failure-isolation scope for each step. State what simulated evidence cannot establish and keep unavailable hardware steps conditional.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Component readiness and revisions | Keeps each step reproducible | Prerequisite configuration |
| Interface dependencies | Determines safe and observable sequence | Added element per step |
| Test equipment and constraints | Exposes simulator limits and stop criteria | Check and evidence table |
Controller first, emulator next, actuator last
Illustrative engineering example.
The fictional bench has a controller, a load emulator and a flight actuator. The emulator can respond to commands, but no evidence says it reproduces the actuator’s inrush or mechanical behavior.
Step path: inspect → controller powered alone → controller + emulator → controller + actuator
Safety procedure and approved electrical limits: project supplied, not invented here| Step and prerequisite | Added element / check | Stop condition and retained evidence | Scope of result |
|---|---|---|---|
| 1. Unpowered inspection; revisions logged | Confirm connector identity and pin map | Stop on mismatch; save photos and revision list | Physical configuration only |
| 2. Approved bench supply and controller ready | Power controller alone; observe self-test/status | Stop on abnormal current; save current trace and log | Controller startup |
| 3. Controller passed step 2 | Connect load emulator; command and acknowledge | Stop on missing response; save both logs | Command path; actuator load unproven |
| 4. Interface limits and hardware release confirmed | Connect flight actuator; observe command, current and movement | Stop on out-of-range current or unexpected motion; save synchronized traces | Actual hardware integration |
This order adds one dependency at a time. Failure at step 3 is confined to the controller-emulator exchange or test setup, while step 4 introduces the real actuator and its harness. Step 4 must wait for the approved hardware and safety constraints, which the example does not supply.
The emulator acknowledgment supports the protocol path only. It cannot demonstrate flight-actuator current, inrush, travel or mechanical end state unless those properties are proven representative. Keeping that limit beside the step prevents simulator success from being mistaken for hardware qualification.
Sequence for observability
- List component readiness, physical dependencies and applicable handling constraints.
- Choose the smallest connected chain with an observable cross-boundary behavior.
- Add one connection or configuration change per isolatable step.
- State stop, safe state and evidence before moving to the next dependency.
Questions about this task
What if the actuator is unavailable?
Complete the emulator step and mark the hardware result pending; keep the plan conditional.
Can a simulated pass close the interface?
Only the behaviors the simulator demonstrably represents. Real electrical and mechanical loads may remain open.
Sources and further reading
- NASA Systems Engineering Handbook: product realization: Interface definition, integration sequence and verification context.
- NASA Systems Engineering Handbook: system design processes: Stakeholder expectations, logical decomposition, functional allocation and design decisions.