Arc Skills / Architecture and engineering budgets
Define a system boundary and external actors
A boundary choice changes what counts as an external Interface and who owns each exchange. Arc Skills takes a mission viewpoint and context evidence and returns a boundary table that makes those choices inspectable.
Use this skill
Use Arc Skills to define the boundary of my System of interest.
Inputs:
- Named System, service objective, operational viewpoint, and ownership scope
- Existing context diagram or adjacent people, environments and Systems
- Normal, startup, maintenance and fault exchanges with source evidence
Return inside/outside classifications and each material, energy, data or command crossing with direction. Explain any boundary-dependent ambiguity and how a changed viewpoint would change the crossing list.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Named system of interest | Fixes the viewpoint and controlled scope | One-sentence boundary statement |
| Adjacent actors and Systems | Identifies true external parties | Inside/outside context table |
| Operational exchanges | Tests the boundary across normal and maintenance phases | Directional crossing list |
Battery monitor versus complete battery assembly
Illustrative engineering example.
In the first illustrative viewpoint, battery-monitor electronics is the system of interest. The battery pack and vehicle controller are separate Systems; a technician acts across the maintenance boundary.
Inside: monitor electronics and its internal logic
Outside: battery pack, vehicle controller, maintenance technician
Changed viewpoint: complete battery assembly includes pack + monitor| Adjacent entity | Inside or outside | Exchange across boundary | Direction |
|---|---|---|---|
| Battery pack | Outside | Cell voltage and temperature signals | Pack → monitor |
| Vehicle controller | Outside | Wake command | Controller → monitor |
| Vehicle controller | Outside | Health/status report | Monitor → controller |
| Maintenance technician | Outside | Inspection request and displayed condition | Technician ↔ monitor, conceptual; physical access TBD |
For the monitor-only viewpoint, pack measurements cross the boundary and need their source, electrical and fault behavior defined. When the system of interest expands to the complete battery assembly, the pack-monitor exchange becomes internal, but the controller and technician interactions remain external. The technician row expresses an operating interaction, not an assumed electronic port. Neither viewpoint is inherently more correct; the mission question determines which is useful.
The sensor’s physical placement is unresolved in this synthetic context. If it is integrated with the pack, it lies outside the monitor boundary; if supplied inside the monitor electronics, the temperature measurement may be internal. Drawing a certain Interface before settling this would mislead downstream allocation.
Draw the line from a named viewpoint
- Write one sentence naming the system of interest and what it controls.
- Classify each adjacent person, environment or System relative to that exact boundary.
- List every material, energy, data or command crossing with direction and operating phase.
- Recheck startup, maintenance and fault cases; record boundary-dependent open choices.
Questions about this task
Does an external technician become a System node?
The context can show the technician as an actor. Only represent a System and Interface relationship where the fixed engineering model and actual exchange support it.
What if the viewpoint changes later?
Re-evaluate which crossings are external and retain the old viewpoint as context; do not silently reinterpret existing interface links.
Sources and further reading
- NASA Systems Engineering Handbook: system design processes: Stakeholder expectations, logical decomposition, functional allocation and design decisions.