[SystemSafety] The States and Modes debate

[Les Chambers]

Peter

Re your comments:

1.

You have a machine which takes inputs and computes on those inputs, and
makes decisions based on

that data. It's a state machine. Obviously. But there is more than one
state machine it implements.

It also implements the qualitative state machine which doesn't work with
the numbers but works with

the categorisation. This state machine is non-deterministic: from "Normal",
performing a "withdraw"

action could lead you to "Normal" or to "Overdrawn". I agree with you that,
in any given context,

you need to be clear which of these state machines you are talking about.

2.

I don't see what you can't have two different words for the same thing.
They are usually called

synonyms. Synonyms are explicitly allowed for in the International
Electrotechnical Vocabulary IEV).

———


As you may have sensed by now, I view any confusion over the definition of
terms in a Safety-Critical system as a serious safety issue.

In some contexts, synonyms are harmless. In others, they can kill.

When the Pilot Monitoring (PM) calls V1, the takeoff decision speed, the
Pilot Flying (PF) knows he/she is committed to take off; any attempt to
abort takeoff after this point stands a high probability of injury and
death.

Analogous conditions were redolent in every chemical reactor control
project I ever participated in. For example, in a reactor with ethylene
oxide as a feedstock, an excess of unreacted oxide meant you were cooking a
bomb that could explode and kill everyone in the plant and the local
neighbourhood to quite a large radius. Ethylene oxide vapour clouds are
used in hyperbaric bombs.  In this case, the audible and visual alarms and
ensuring state changes need to be unambiguous.

In these contexts, synonyms abominate the functional Safety countryside.
They must be hunted down and eliminated with extreme prejudice - along with
the “qualitative state machine(s)” they rode in on. Nature does not reward
Humpty Dumpty engineering.


My remedy is as follows:

Let us abandon “qualitative” and pursue determinism with vigour. The labels
state and mode qualify as “Design Entitles” as defined in detail in IEEE
Standard 1016 1998, the standard for Software Design Descriptions (para 5.2
Design entities), which states “*A design entity is an element (component)
of a design that is structurally and functionally distinct from other
elements and that is separately named and referenced. *

*The standard (bless its cotton socks) goes on to describe 10 attributes of
a design entity in glorious detail. Here is our path to the forms of pure
truth.* So come with me back down the rabbit hole to Wonderland (where the
inhabitants freely admit they are all mad - could the Cheshire Cat on a
standards committee be a  benefit?)

See:

https://bit.ly/4fvg8Ha

{Search text: The labels state and mode qualify as “Design Entitles” }

Where I pose the question:

… does any entity that issues standards or guides to systems engineering
(IEEE, IEC, CENELEC, DoD, NASA, INCOSE, Nuclear Regulatory Commission)
attempt to provide a precise definition of both state and mode in these
terms? If not with your knowledge of systems engineering, could you attempt
such a definition that might differentiate a state from a mode?


*I trust this dialogue indicates a path to clarification.*

*Seriously guys, this mess does need to be cleaned up.*


*Over to you all. *

*Cheshire cat-like, I'll fade out on this issue with a verse I composed to
give young control systems engineers pause when tempted to wander off the
path of determinism towards qualitativeness.*


*A broken wing*

*rocks on the sand*

*beside a far**-**off sea.*

*In pitch black *

*faith was placed in men*

*Christ!*

*One of them was me.*


*Cheers *

*Les*

On Thu, 21 May 2026 at 17:48, Prof. Dr. Peter Bernard Ladkin <
ladkin at causalis.com> wrote:

> On 2026-05-21 03:10 , Les Chambers wrote:
> >
> > Can I confirm that we agree the following statement is true?
> >
> > In finite state modelling, the terms "mode" and "state" are synonymous.
> >
> No, most definitely not.
>
> Mode and state for APs are two architecturally different things, but the
> (specification of) AP
> functioning is a finite state machine. i don't know why I need to repeat
> this.
>
> PBL
>
> Prof. Dr. Peter Bernard Ladkin
> Causalis Limited/Causalis IngenieurGmbH, Bielefeld, Germany
> Tel: +49 (0)521 3 29 31 00
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/pipermail/systemsafety/attachments/20260522/48e0d6b6/attachment-0001.html>