<html aria-label="message body">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div><br>
</div>
PBL,
<div><br>
</div>
<div><i>“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></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
<div><i>“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.”</i></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
<div><i>“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.”</i></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
<div><i>“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.)”</i></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
<div>— steve</div>
<div><br>
</div>
<div><br>
</div>
<div><br id="lineBreakAtBeginningOfMessage">
<div><br>
<div>On May 20, 2026, at 4:48 AM, Prof. Dr. Peter Bernard Ladkin <ladkin@causalis.com> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div>On 2026-05-19 20:23 , Steve Tockey wrote:<br>
<blockquote type="cite">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”.<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite">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.<br>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
"Mode" itself is more entertaining than Les adduced. To electrotechnologists it is, quite literally, one solution of Maxwell's equations.<br>
<br>
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"<br>
<br>
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.)<br>
<br>
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".<br>
<br>
The IEV, BTW, is on-line at https://www.electropedia.org/<br>
<br>
PBL<br>
<br>
Prof. Dr. Peter Bernard Ladkin<br>
Causalis Limited/Causalis IngenieurGmbH, Bielefeld, Germany<br>
Tel: +49 (0)521 3 29 31 00<br>
<br>
</div>
</div>
</div>
<br>
</div>
</body>
</html>