Arc Skills / Architecture and engineering budgets
Review system modes and transitions
Modes define what the System may do at a given instant, including during conflicting events. Arc Skills takes a statechart or table and returns an event-by-mode review with unresolved authority visible.
Use this skill
Use Arc Skills to review my System mode and transition definitions.
Inputs:
- Current mode table or statechart with allowed actions and entry conditions
- Event sources, guards, operator commands, fault events and priority rules
- Relevant scenarios, Interfaces, restart and confirmation requirements
Return an event-by-mode transition review covering simultaneous, repeated and interrupted events. Mark unstated precedence or authority as unresolved rather than selecting a rule silently.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Mode definitions | States allowed and prohibited functions | Mode permission table |
| Triggers and guards | Tests transition determinism | Event-by-mode findings |
| Operator and fault requirements | Checks observable denial and restart | Priority and confirmation questions |
Standby receives two events at once
Illustrative engineering example.
A fictional radio has Standby and Transmit modes. The draft allows a transmit request in Standby and separately says an inhibit event shall stop transmission. It does not state how simultaneous events are ordered or what an inhibit event alone does in Standby.
Modes: Standby, Transmit
Events: request transmit, inhibit
Initial mode: Standby
Simultaneous case: both events in one controller cycle| Current mode and event | Stated rule | Result | Finding |
|---|---|---|---|
| Standby + transmit request | Enter Transmit | Transmit | Defined if request arrives alone |
| Transmit + inhibit | Return to Standby | Transmit stops | Defined if inhibit arrives alone |
| Standby + inhibit | Stop-transmission rule only; no standby effect stated | No transmission requested | Stay in Standby is plausible but not explicitly defined |
| Standby + both events | No priority or guard stated | Transmit or remain Standby | Conflict; owner must set precedence |
The last row is not solved by listing the two events separately. If the request is processed first, a brief transmit may occur; if inhibit is processed first, it may never begin. The difference matters to the operator and any attached receiver. A proposed “inhibit wins” rule needs approval, then a denial or inhibited-status indication can be verified.
The same exercise should include repeated commands, interrupted transitions and restart only where those events occur in the product’s scope. Keeping connectivity as a separate attribute may avoid an oversized mode list, but the interface still needs to say which commands are available in each combined condition.
Test transitions as decisions
- For each mode, list allowed functions, prohibited actions and entry evidence.
- Record source, target, trigger, guard, effect and confirmation for every transition.
- Inject simultaneous and repeated events to find incompatible results.
- Assign each unresolved precedence or restart rule to the responsible owner.
Questions about this task
Is simultaneous arrival realistic?
Even if events are serialized in software, one cycle can observe both. The ordering rule should be explicit if outcomes differ.
Can the review choose a safe priority?
It can propose one with rationale, but it cannot treat that proposal as the governing mode rule.
Sources and further reading
- NASA Systems Engineering Handbook: system design processes: Stakeholder expectations, logical decomposition, functional allocation and design decisions.