[SystemSafety] The States and Modes debate

Wed May 20 11:19:09 CEST 2026

My apologies, all.

In my naivete, I've opened a can of worms. It turns out the systems
engineering profession has collectively fallen down a rabbit hole with
Alice and her adventures in Wonderland, and later Through the Looking
Glass, where she meets Humpty Dumpty, who by Fiat announces, “When I use a
word, it means just what I choose it to mean — neither more nor less.”

This is pretty much where we stand. If you enjoy a good laugh, continue
reading my dialogue with Gemini here:

https://bit.ly/3RPoHTg

Scroll down to my prompt, “Do IEC 61508 and EN 50128 refer to states or
modes or both” and read on.

As you scroll through the pronouncements of the IEC, CENELEC, US DoD and
finally the IEEE (Gasp! - *O Captain! my Captain!)*. You may reach my
conclusion that this is an omelette that cannot be unscrambled. You might
as well demand the Americans put the U back in color (a righteous though
futile *Don Quixote-like *mission - so easily led those guys; Noah Webster
says, "I pulled it out for simplicity", and no one complains?)

All I can say before I ride off to tilt at other windmills:

1. PBL, you have my blessing to call a mode a mode along with millions of
other pilots in the world; while we, in our subset of chemical processing
control systems practitioners, will continue to colloquialize “step” for
state and “sequence control unit” for state engine. Let's not mess with
anything that works.

2. Phil, my humble suggestion is that you tell your students that the
semantics of state and mode are a function of the application Domain. For
example, if you land in DoD weapon systems, you'd better assume the local
mode lingo or be strung up by some hard-driving CAG.

3. Steve, I am interested in how you would explain the concept of state and
state engine to a plant operator. Back in the day, my colleagues and I had
great success using “step” and “sequence control unit.” Not once but
hundreds of times in plants throughout the USA, Germany, the Netherlands,
South America, Australia; across cultures, across languages; to an eclectic
band of operators ranging from good old boys without a high school
education to university graduates.

My view is that the overarching issue here is cognition achieved through
shared mental models and impedance matching. The operator must be part of,
inside the boundary of, the scope of automation. The operator's brain must
share the mental model of the silicon. The sharing can only occur if there
is a total impedance match between mentor and student as the model concept
is passed. It turns out that at our most primal level, we human beings are
pattern matchers. All control rooms I ever inhabited had a simple state
diagram, the defining pattern, pinned to the wall.

Lastly, in the chemical processing context, we are able to use the state
engine in all life cycle phases from requirements definition to
implementation to operations. This was only possible because the plant
engineers wrote the programs and lived with the plant in operations. I had
a hand in training some of these guys. Looking back, it is clear to me that
there could be no ambiguity about the definition of state. It was a safety
issue.

So Phil, graduating engineers who go out into the world looking for states
and modes as separate entities is wasting their brain cycles and a
potential hazard.

It's comforting that Gemini, sort of, agrees with me. I cite its conclusion
if you scroll down to the bottom.

*“The Verdict on Your Assertion*

Your assertion that the industry should "cease and desist" from using both
terms is backed up by the IEEE's own documentation.

If you look at the *IEEE definition of a Finite State Machine (FSM)*:

*"A computational model consisting of a finite number of states and
transitions between those states..."*

There is no mention of "modes" in the mathematics of state machines.
Computer scientists and automation engineers using IEEE standards can
completely specify, verify, and execute complex, safe system behaviors
using *only* states.

The IEEE maintains "mode" in its vocabulary database not out of
mathematical necessity, but out of *legacy compliance*—purely to
accommodate the operational, user-facing language used by pilots, drivers,
and defense customers who want to see the word "Mode" on their control
panels. Structurally, it remains a redundant concept.”

Hallelujah brother. Praise the Lord and pass the specification!

Les

On Wed, 20 May 2026 at 04:23, Steve Tockey <steve.tockey at construx.com>
wrote:

>
> 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:
>
> [image: 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> 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
>> 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/20260520/b18b5b10/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.png
Type: image/png
Size: 100848 bytes
Desc: not available
URL: <https://lists.techfak.uni-bielefeld.de/pipermail/systemsafety/attachments/20260520/b18b5b10/attachment-0001.png>