[SystemSafety] The States and Modes debate

Tue May 19 20:23:21 CEST 2026

I’ll stir the pot a bit more here, because it’s been an issue in what I’ve been facing over the years. That issue is the difference between the Finite Automata view of the word “state” vs. a purely mathematical, e.g., Abstract Data Type, view of that same word.

If we take as an example a mythical Bank Account. Data attributes of this mythical Bank Account class would include at least the following:

.balance — how much money is held in the bank account right now
.overdraft limit — how much the account’s owners are allowed to let the balance go negative, i.e., a very short term loan

In a Finite Automata view of the behavior of Bank Accounts, we might have the following UML Statechart:

[PastedGraphic-1.png]

Simple. Two states: Normal and Overdrawn. In the Normal state, the owners have full ability to deposit and withdraw so long as any one withdrawal does not allow the account balance to go below the negative of the overdraft limit. E.g, an account’s .balance is 400.00 Euros, and the overdraft limit is 200.00 Euros. Any attempt to withdraw of between 0.01 Euro and 400.00 Euros would be allowed and leave the account in the Normal state. Any attempt to withdraw of between 400.01 Euros and 600.00 Euros would also be allowed but would leave the account in the Overdrawn state. Any attempt to withdraw more than 600.00 Euros would be ignored. When the account is in the Overdrawn state, all requests to withdraw any amount are refused. In the Overdrawn state, only deposits are allowed until the .balance is back to at least 0.00 Euros. So my point here is that in the Finite Automata view of the universe, “states” are defined in terms of the state-level responses that happen as a result of the events (and, possibly, event parameter values). Whether the account’s .balance is 400.00 Euros or 4000.00 Euros, a request to withdraw 200.00 Euros will be treated the same way. Les’s view, and mine too.

However, in the purely mathematical / Abstract Data Type view of the world, merely changing the .balance of the account from 400.00 Euros to 400.01 Euros changes its state. In the Abstract Data Type world, state is defined strictly by the properties and values that make up the data. Because the .balance is a defining property of a bank account's state, accounts with different balances hold distinctly different states.

This is not to say that those two views are fundamentally irreconcilable. The “States” in the Finite Automata world correspond directly to Equivalence Classes of “States” in the Abstract Data Type world where the responses to events in any Equivalene Class are the same from a “response to the next event” perspective.

So on the one hand, I’m agreeing with Les that there is a problem with how INCOSE views “state” and “mode”. On the other hand, I’m also pointing out that to the extent that pure math people get involved, the meaning of the word “state” itself becomes ambiguous even if you completely outlaw the word “mode”.

The bottom line is that if you want people to truly understand what you’re talking about, you need to precisely define your terms, and use those terms consistent with their definitions. Further, if there are two different terms, then there must be unique and meaningfully different definitions of those different terms, particularly when those terms carry similar or overlapping meanings in common use. To do otherwise is sloppy and unprofessional.

And, Les, for what it’s worth, to me the word “mode” means “the value that appears most frequently in the data set”.  (Smile)

— steve

On May 19, 2026, at 2:14 AM, Les Chambers <les at chambers.com.au> wrote:

Agreed, mode confusion in aerospace is a lethal issue, and it’s exactly why I argue we need absolute semantic clarity in our engineering standards.

My grievance isn’t with the colloquial use of the word 'mode' by operators or pilots. My grievance is with INCOSE—a  premier international systems engineering body—explicitly stating that a State and a Mode are different entities, yet failing to provide a rigorous, structural definition to separate them.

If we are to assert that they are distinct architectural concepts, we should be able to define them by their attributes.

From a systems engineering and computer science perspective, a State is a well-defined condition of a system, governed by an internal data structure (variables, inputs, and history) that determines how it responds to a given set of inputs.

To help me bridge the gap between aerospace practice and rigorous systems modelling, how would you define the unique attributes of a Mode versus a State?

  *   Where do their data attributes actually differ?

  *   Is a 'mode' simply a higher-level abstraction (a 'super-state' or collection of sub-states, like an autopilot operational regime)? This is hard to justify as David Harel’s Statecharts (and subsequently UML/SysML) solved this decades ago without needing the word "mode." They introduced composite states (states within states) and orthogonal/concurrent states (parallel state machines I applied extensively in chemical processing).

  *   Or does it possess fundamentally different behavioural properties that a classic finite state machine cannot capture?

I contend that if a 'mode' can be entirely modelled, verified, and executed using standard state-engine logic, then introducing it as a fundamentally distinct entity in a foundational handbook—without definition—only invites the very 'mode confusion' Sarter and Woods warned us about."

There is a path to the truth. I assert that modelling a State as an entity defined by system attributes, invariants, and relationships, will reveal that what the industry calls a "mode" is structurally identical to a state.

Les

On Tue, 19 May 2026 at 17:10, Prof. Dr. Peter Bernard Ladkin <ladkin at causalis.com<mailto:ladkin at causalis.com>> wrote:
On 2026-05-19 09:03 , Les Chambers wrote:
> My view is that the word "mode" needs to be banished from the face of the Earth!

Modes are essential when talking about autopilots, and have been for 30 years, ever since "mode
confusion" was introduced in Woods and Sarter's analysis of A320 AP workings.

PBL

Prof. Dr. Peter Bernard Ladkin
Causalis Limited/Causalis IngenieurGmbH, Bielefeld, Germany
Tel: +49 (0)521 3 29 31 00

_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE<mailto:systemsafety at TechFak.Uni-Bielefeld.DE>
Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE
Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/pipermail/systemsafety/attachments/20260519/7ba0bf39/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.png
Type: image/png
Size: 100848 bytes
Desc: PastedGraphic-1.png
URL: <https://lists.techfak.uni-bielefeld.de/pipermail/systemsafety/attachments/20260519/7ba0bf39/attachment-0001.png>