[SystemSafety] The States and Modes debate

[Steve Tockey]

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/20260520/c841c20c/attachment-0001.html>