Arc Skills / Architecture and engineering budgets
Allocate system functions to subsystems
Functional allocation answers who controls each outcome rather than merely naming a component. Arc Skills takes a function list and subsystem tree and returns an owner matrix with uncovered or disputed behavior.
Use this skill
Use Arc Skills to allocate my required functions to the proposed subsystem architecture.
Inputs:
- Functional requirements or source function list with identifiers and modes
- Current subsystem tree, architecture revision, and responsibility constraints
- Cross-subsystem inputs, commands, status, and off-nominal scenarios
Return an owner/contributor matrix with triggers, outputs, Interface dependencies, and missing or disputed decisions. Preserve source wording and keep proposed allocations distinct from approved ones.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Functional requirements and scenarios | Identify triggers, decisions and observable outputs | Traceable function rows |
| Subsystem hierarchy | Offers candidate accountable owners | Owner and contributor assignments |
| Interface evidence and modes | Shows which information crosses a boundary | Conflict and missing-exchange register |
Who owns heater inhibit?
Illustrative engineering example.
In this illustrative thermal-control assembly, a sensor reports temperature, a controller computes demand, and a power unit switches the heater. Two illustrative source drafts both claim authority to inhibit heating, while no priority rule is supplied.
Thermal assembly
├─ Temperature sensor
├─ Thermal controller
└─ Power unit → heater
Mode: normal heating; fault response considered separately| Function / trigger | Accountable owner | Contributors and exchange | Finding |
|---|---|---|---|
| Measure temperature / sample tick | Temperature sensor | Temperature data → controller | Owner clear; range and freshness TBD |
| Compute heat demand / new sample | Thermal controller | Sensor data in; heater request out | Controller owns decision to request heat |
| Switch heater / valid request | Power unit | Request from controller; heater current out | Power unit owns switching action |
| Inhibit heating / fault or overtemperature | Unresolved | Controller and power-unit drafts both claim decision | Choose authority and priority before allocating |
The display, if present, may report temperature but does not own the heating decision. Keeping one accountable decision owner for each function makes the fault path testable: detection, decision, actuation and reporting can each be traced.
The conflict is real even if both devices have protective mechanisms. One may independently cut power while the other issues a normal inhibit command, but that distinction must be written and reflected in modes and interfaces. The matrix does not decide safety authority on the team’s behalf.
Build the allocation matrix
- Extract each function with its trigger, input, output and operating mode from controlled sources.
- Assign the subsystem controlling the observable outcome; list sensors or switches as contributors when appropriate.
- Trace every cross-subsystem exchange and flag missing data, status or decision priority.
- Walk a fault case to see who detects, decides, acts and reports.
Questions about this task
Can two subsystems share a function?
They can contribute, but the allocation should still name the decision owner or explicitly split the function into separate controlled outcomes.
Is a proposed matrix a new architecture baseline?
No. It is a review artifact until the responsible owners accept the responsibility and interface changes.
Sources and further reading
- NASA Systems Engineering Handbook: system design processes: Stakeholder expectations, logical decomposition, functional allocation and design decisions.