[SystemSafety] The States and Modes debate

[Prof. Dr. Peter Bernard Ladkin]

On 2026-05-19 20:23 , Steve Tockey wrote:
> 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”.

Being a "pure math person" (amongst other things), I would rather describe the situation as follows. 
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.

> 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.

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). 
EUC is a synonym for "equipment under control", for example.

I've been professionally involved in terminology for quite a while, and am currently the German rep 
to IEC TC1, the committee which maintains the IEV. So  I like to think I am familiar with the issues 
which arise. Les wanted to "banish" the word "mode" because (as far as I can tell) he used to work 
in industrial control engineering, and didn't like the proposal from INCOSE for a meaning for "mode" 
- he had other terminology.

Examples are legion in which a specific term has different meanings depending on what branch you are 
working in. People try, such as here INCOSE, to give a "general" meaning to apply to all system 
engineering, but they are often going to fail. It doesn't necessarily mean the effort to be 
as-emcompassing-as-possible is not worth it.

Take the term "wing" for example. The meanings for birds and aircraft are similar (but not 
identical: wings for birds are means of propulsion, but not for aircraft). But neither has anything 
to do with buildings (the "East Wing" which is no more) or grand pianos (whose designation in German 
is "Flügel", i.e., "wing"). Trying to come up with a definition which incompasses all four uses and 
doesn't use case distinctions would not only likely be a failure but also pointless: we have 
perfectly good explanations for birds, for airplanes, for buildings, and for pianos. What's wrong 
with a "CASE" statement?

"Mode" itself is more entertaining than Les adduced. To electrotechnologists it is, quite literally, 
one solution of Maxwell's equations.

The reason is as follows. The IEV has many entries (which include multi-word terms) in which "mode" 
is one word. But there are only two entries for "mode" as a standalone: 731-03-04 in which it is 
"one solution of Maxwell's equations, representing an electromagnetic field in a certain space 
domain and belonging to a family of independent solutions defined by specified boundary conditions" 
and 904-03-09 in which it is "distinct status or distinct operating condition of a system"

The rules of the IEV is that, where there are homonyms, as here, the definition that appears with 
the lowest part number is *the* meaning -- here Part 731, Optical Fiber Communications -- and 
(ideally) the other must be resolved, which is often achieved by appending a "tag", a syntactic part 
of the entry, restricting the domain of use. ("Tag" is my informal word: the IEC does not have a 
formal word for this domain-restriction item, which appears in angle brackets. I have proposed that 
IEC both give it a name and issue guidance for how it is to be used. Such guidance should appear in 
the new Guide 128 on IEV entries, of which I am nominally on the authoring committee. But the 
committee has yet to consider any of my proposals.)

IEV Part 351, Control Technology, which is the Part relating to the area in which Les says he 
worked, has no standalone entry, but is does have entries for "mode-based control" and for 
"operating mode".

The IEV, BTW, is on-line at https://www.electropedia.org/

PBL

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