[SystemSafety] The States and Modes debate

[Les Chambers]

Can I confirm that we agree the following statement is true?

In finite state modelling, the terms "mode" and "state" are synonymous.

The standards in our corpus use these terms inconsistently. See:

https://bit.ly/4upsMMo

Scroll to the bottom and back up till you find the prompt:

“Please find citations from systems engineering guides and standards of
IEEE, DoD, CENELEC, IEC, INCOSE - that identify "states and modes" of a
system in a way that implies they are not synonyms but separate, …”

We are stuck with this ambiguity. The simple solution is to use only one of
these terms consistently throughout an application Domain.

Les

On Thu, 21 May 2026 at 05:57, Steve Tockey <steve.tockey at construx.com>
wrote:

>
> PBL,
>
> *“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.”*
>
> To me, synonyms are not nearly as fatally risky as using undefined,
> ill-defined, or inconsistently-used words. It’s more a matter of
> inconvenience to the receiver to then have to figure out if the terms are
> merely synonyms or if there really is a significantly different meaning
> intended by the use of the different terms. Don’t force the reader to do
> any more work than they already have to. That’s what I see Les’ original
> problem as: use of words that might be synonyms, or might not be, without
> ever being at all clear about which situation it was.
>
>
> *“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.”*
>
> While he did explicitly say that, I think he would have still been happy
> enough if the authors had provided sufficient content to be clear about
> whether “State" and “Mode" were synonyms or not, and if they were not
> synonyms then what was the relevant difference in meaning between them.
>
>
> *“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.”*
>
> Then I would recommend that they adopt a mechanism like UML’s Profile that
> allows people to be precise—within their context—about how they are using
> their terms. Be general when it doesn’t cause significant interpretational
> problems. But allow the precision to be layered on when differences in
> interpretation could be significant.
>
>
> *“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.)”*
>
> Aha, that looks to me a lot like the beginnings of a Profile mechanism. I
> would encourage IEV and INCOSE to be more serious and explicit about
> incorporating some kind of more formal Profile mechanism, particularly when
> safety- or mission-criticality is important.
>
> Incidentally, one part of UML’s Profile mechanism is called “Stereotype”
> and uses some name enclosed by guillemets (« » or, if guillemets proper are
> unavailable, double angle brackets << >>) and placed above or before the
> name of another element. That seems notationally similar to what you called
> “tag”. UML also includes at least two other explicit mechanisms, one called
> “tagged values” which are probably inappropriate for IEV. The other is
> called “Constraints”, which express restricted logical relationships
> between things. Then there’s the implicit mechanism of just providing more
> precise and limited definitions for how terms are being used in any
> particular context.
>
>
> — steve
>
>
>
>
> On May 20, 2026, at 4:48 AM, Prof. Dr. Peter Bernard Ladkin <
> ladkin at causalis.com> wrote:
>
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/pipermail/systemsafety/attachments/20260521/a9db3b8a/attachment-0001.html>