<div dir="ltr">
<p class="gmail-p1" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica;color:rgb(29,28,23)"><span class="gmail-s1" style="font-kerning:none">My apologies, all.<span class="gmail-Apple-converted-space"> </span></span></p>
<p class="gmail-p1" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica;color:rgb(29,28,23)"><span class="gmail-s1" style="font-kerning:none">In my naivete, I've opened a can of worms. It turns out the systems engineering profession has collectively fallen down a rabbit hole with Alice and her adventures in Wonderland, and later Through the Looking Glass, where she meets Humpty Dumpty, who by Fiat announces, “</span><span class="gmail-s2" style="font-kerning:none;background-color:rgb(249,246,242)">When I use a word, it means just what I choose it to mean — neither more nor less.”</span></p>
<p class="gmail-p2" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica;color:rgb(29,28,23);background-color:rgb(249,246,242)"><span class="gmail-s1" style="font-kerning:none">This is pretty much where we stand. If you enjoy a good laugh, continue reading my dialogue with Gemini here:</span></p>
<p class="gmail-p3" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:16px;line-height:normal;font-family:Helvetica;color:rgb(29,28,23)"><span class="gmail-s1" style="font-kerning:none"><a href="https://bit.ly/3RPoHTg">https://bit.ly/3RPoHTg</a></span></p>
<p class="gmail-p4" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica;color:rgb(0,0,0)"><span class="gmail-s3" style="font-kerning:none;color:rgb(29,28,23);background-color:rgb(249,246,242)">Scroll down to my prompt, </span><span class="gmail-s4" style="font-kerning:none">“</span><span class="gmail-s1" style="font-kerning:none">Do IEC 61508 and EN 50128 refer to states or modes or both” and read on.</span></p>
<p class="gmail-p4" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica;color:rgb(0,0,0)"><span class="gmail-s1" style="font-kerning:none">As you scroll through the pronouncements of the IEC, CENELEC, US DoD and finally the IEEE (Gasp! - </span><span class="gmail-s5" style="font-kerning:none;color:rgb(10,10,10)"><b>O Captain! my Captain!)</b></span><span class="gmail-s1" style="font-kerning:none">. You may reach my conclusion that this is an omelette that cannot be unscrambled. You might as well demand the Americans put the U back in color (a righteous though futile </span><span class="gmail-s5" style="font-kerning:none;color:rgb(10,10,10)"><b>Don Quixote-like </b></span><span class="gmail-s1" style="font-kerning:none">mission - so easily led those guys; Noah Webster says, "I pulled it out for simplicity", and no one complains?)</span></p>
<p class="gmail-p5" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:16px;line-height:normal;font-family:Helvetica;color:rgb(29,28,23)"><span class="gmail-s1" style="font-kerning:none">All I can say before I ride off to tilt at other windmills:</span></p>
<p class="gmail-p5" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:16px;line-height:normal;font-family:Helvetica;color:rgb(29,28,23)"><span class="gmail-s1" style="font-kerning:none">1. PBL, you have my blessing to call a mode a mode along with millions of other pilots in the world; while we, in our subset of chemical processing control systems practitioners, will continue to colloquialize “step” for state and “sequence control unit” for state engine. Let's not mess with anything that works.</span></p>
<p class="gmail-p5" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:16px;line-height:normal;font-family:Helvetica;color:rgb(29,28,23)"><span class="gmail-s1" style="font-kerning:none">2. Phil, my humble suggestion is that you tell your students that the semantics of state and mode are a function of the application Domain. For example, if you land in DoD weapon systems, you'd better assume the local mode lingo or be strung up by some hard-driving CAG.</span></p>
<p class="gmail-p5" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:16px;line-height:normal;font-family:Helvetica;color:rgb(29,28,23)"><span class="gmail-s1" style="font-kerning:none">3. Steve, I am interested in how you would explain the concept of state and state engine to a plant operator. Back in the day, my colleagues and I had great success using “step” and “sequence control unit.” Not once but hundreds of times in plants throughout the USA, Germany, the Netherlands, South America, Australia; across cultures, across languages; to an eclectic band of operators ranging from good old boys without a high school education to university graduates.</span></p>
<p class="gmail-p5" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:16px;line-height:normal;font-family:Helvetica;color:rgb(29,28,23)"><span class="gmail-s1" style="font-kerning:none">My view is that the overarching issue here is cognition achieved through shared mental models and impedance matching. The operator must be part of, inside the boundary of, the scope of automation. The operator's brain must share the mental model of the silicon. The sharing can only occur if there is a total impedance match between mentor and student as the model concept is passed. It turns out that at our most primal level, we human beings are pattern matchers. All control rooms I ever inhabited had a simple state diagram, the defining pattern, pinned to the wall.</span></p>
<p class="gmail-p5" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:16px;line-height:normal;font-family:Helvetica;color:rgb(29,28,23)"><span class="gmail-s1" style="font-kerning:none">Lastly, in the chemical processing context, we are able to use the state engine in all life cycle phases from requirements definition to implementation to operations. This was only possible because the plant engineers wrote the programs and lived with the plant in operations. I had a hand in training some of these guys. Looking back, it is clear to me that there could be no ambiguity about the definition of state. It was a safety issue.<span class="gmail-Apple-converted-space"> </span></span></p>
<p class="gmail-p5" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:16px;line-height:normal;font-family:Helvetica;color:rgb(29,28,23)"><span class="gmail-s1" style="font-kerning:none">So Phil, graduating engineers who go out into the world looking for states and modes as separate entities is wasting their brain cycles and a potential hazard.</span></p>
<p class="gmail-p6" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:16px;line-height:normal;font-family:Helvetica;color:rgb(29,28,23);min-height:19px"><span class="gmail-s1" style="font-kerning:none"></span><br></p>
<p class="gmail-p5" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:16px;line-height:normal;font-family:Helvetica;color:rgb(29,28,23)"><span class="gmail-s1" style="font-kerning:none">It's comforting that Gemini, sort of, agrees with me. I cite its conclusion if you scroll down to the bottom.</span></p>
<p class="gmail-p7" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:18px;line-height:normal;font-family:Times"><span class="gmail-s1" style="font-kerning:none"><b>“The Verdict on Your Assertion</b></span></p>
<p class="gmail-p8" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none">Your assertion that the industry should "cease and desist" from using both terms is backed up by the IEEE's own documentation.</span></p>
<p class="gmail-p8" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none">If you look at the <b>IEEE definition of a Finite State Machine (FSM)</b>:</span></p>
<p class="gmail-p8" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none"><i>"A computational model consisting of a finite number of states and transitions between those states..."</i><i></i></span></p>
<p class="gmail-p8" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none">There is no mention of "modes" in the mathematics of state machines. Computer scientists and automation engineers using IEEE standards can completely specify, verify, and execute complex, safe system behaviors using <i>only</i> states.</span></p>
<p class="gmail-p8" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none">The IEEE maintains "mode" in its vocabulary database not out of mathematical necessity, but out of <b>legacy compliance</b>—purely to accommodate the operational, user-facing language used by pilots, drivers, and defense customers who want to see the word "Mode" on their control panels. Structurally, it remains a redundant concept.”</span></p>
<p class="gmail-p9" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica;min-height:17px"><span class="gmail-s1" style="font-kerning:none"></span><br></p>
<p class="gmail-p8" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none">Hallelujah brother. Praise the Lord and pass the specification!</span></p><p class="gmail-p8" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none"><br></span></p><p class="gmail-p8" style="margin:0px;font-style:normal;font-variant:normal;font-size-adjust:none;font-kerning:auto;font-feature-settings:normal;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica"><span class="gmail-s1" style="font-kerning:none">Les</span></p></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, 20 May 2026 at 04:23, Steve Tockey <<a href="mailto:steve.tockey@construx.com">steve.tockey@construx.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div><br>
</div>
<div>I’ll stir the pot a bit more here, because it’s been an issue in what I’ve been facing over the years. That issue is the difference between the Finite Automata view of the word “state” vs. a purely mathematical, e.g., Abstract Data Type, view of that same
word.</div>
<div><br>
</div>
<div>If we take as an example a mythical Bank Account. Data attributes of this mythical Bank Account class would include at least the following:</div>
<div><br>
</div>
<div>.balance — how much money is held in the bank account right now</div>
<div>.overdraft limit — how much the account’s owners are allowed to let the balance go negative, i.e., a very short term loan</div>
<div><br>
</div>
<div>In a Finite Automata view of the behavior of Bank Accounts, we might have the following UML Statechart:</div>
<div><br>
</div>
<div><img alt="PastedGraphic-1.png" src="cid:ii_19e44ada05c5b206ef61"></div>
<div><br>
</div>
<div> </div>
<div>Simple. Two states: Normal and Overdrawn. In the Normal state, the owners have full ability to deposit and withdraw so long as any one withdrawal does not allow the account balance to go below the negative of the overdraft limit. E.g, an account’s .balance
is 400.00 Euros, and the overdraft limit is 200.00 Euros. Any attempt to withdraw of between 0.01 Euro and 400.00 Euros would be allowed and leave the account in the Normal state. Any attempt to withdraw of between 400.01 Euros and 600.00 Euros would also
be allowed but would leave the account in the Overdrawn state. Any attempt to withdraw more than 600.00 Euros would be ignored. When the account is in the Overdrawn state, all requests to withdraw any amount are refused. In the Overdrawn state, only deposits
are allowed until the .balance is back to at least 0.00 Euros. So my point here is that in the Finite Automata view of the universe, “states” are defined in terms of the state-level responses that happen as a result of the events (and, possibly, event parameter
values). Whether the account’s .balance is 400.00 Euros or 4000.00 Euros, a request to withdraw 200.00 Euros will be treated the same way. Les’s view, and mine too.</div>
<div><br>
</div>
<div>However, in the purely mathematical / Abstract Data Type view of the world, merely changing the .balance of the account from 400.00 Euros to 400.01 Euros changes its state. In the Abstract Data Type world, state is defined strictly by the properties and
values that make up the data. Because the .balance is a defining property of a bank account's state, accounts with different balances hold distinctly different states.</div>
<div><br>
</div>
<div>This is not to say that those two views are fundamentally irreconcilable. The “States” in the Finite Automata world correspond directly to Equivalence Classes of “States” in the Abstract Data Type world where the responses to events in any Equivalene Class
are the same from a “response to the next event” perspective.</div>
<div><br>
</div>
<div>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”.</div>
<div><br>
</div>
<div>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. To do otherwise is sloppy and unprofessional.</div>
<div><br>
</div>
<div>And, Les, for what it’s worth, to me the word “mode” means “the value that appears most frequently in the data set”. (Smile)</div>
<div><br>
</div>
<div><br>
</div>
<div>— steve</div>
<div><br>
</div>
<br id="m_3528005984989249377lineBreakAtBeginningOfMessage">
<div><br>
<div>On May 19, 2026, at 2:14 AM, Les Chambers <<a href="mailto:les@chambers.com.au" target="_blank">les@chambers.com.au</a>> wrote:</div>
<br>
<div>
<div dir="ltr">
<p>Agreed, mode confusion in aerospace is a lethal issue, and it’s exactly why I argue we need absolute semantic clarity in our engineering standards.</p>
<p>My grievance isn’t with the <i>colloquial</i> use of the word 'mode' by operators or pilots. My grievance is with INCOSE—a premier international systems engineering body—explicitly stating that a State and a Mode are
<i>different entities</i>, yet failing to provide a rigorous, structural definition to separate them.</p>
<p>If we are to assert that they are distinct architectural concepts, we should be able to define them by their attributes.</p>
<p>From a systems engineering and computer science perspective, a <b>State</b> is a well-defined condition of a system, governed by an internal data structure (variables, inputs, and history) that determines how it responds to a given set of inputs.</p>
<p>To help me bridge the gap between aerospace practice and rigorous systems modelling, how would you define the unique attributes of a
<b>Mode</b> versus a <b>State</b>?</p>
<ul>
<li>
<p>Where do their data attributes actually differ?</p>
</li><li>
<p>Is a 'mode' simply a higher-level abstraction (a 'super-state' or collection of sub-states, like an autopilot operational regime)? This is hard to justify as David Harel’s Statecharts (and subsequently UML/SysML) solved this decades ago without needing the
word "mode." They introduced <b>composite states</b> (states within states) and <b>
orthogonal/concurrent states</b> (parallel state machines I applied extensively in chemical processing).</p>
</li><li>
<p>Or does it possess fundamentally different behavioural properties that a classic finite state machine cannot capture?</p>
</li></ul>
<p>I contend that if a 'mode' can be entirely modelled, verified, and executed using standard state-engine logic, then introducing it as a fundamentally
<i>distinct entity</i> in a foundational handbook—without definition—only invites the very 'mode confusion' Sarter and Woods warned us about."</p>
<p>There is a path to the truth. I assert that modelling a State as an entity defined by system attributes, invariants, and relationships, will reveal that what the industry calls a "mode" is structurally identical to a state.<br>
<br>
Les</p>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, 19 May 2026 at 17:10, Prof. Dr. Peter Bernard Ladkin <<a href="mailto:ladkin@causalis.com" target="_blank">ladkin@causalis.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 2026-05-19 09:03 , Les Chambers wrote:<br>
> My view is that the word "mode" needs to be banished from the face of the Earth!<br>
<br>
Modes are essential when talking about autopilots, and have been for 30 years, ever since "mode
<br>
confusion" was introduced in Woods and Sarter's analysis of A320 AP workings.<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>
_______________________________________________<br>
The System Safety Mailing List<br>
<a href="mailto:systemsafety@TechFak.Uni-Bielefeld.DE" target="_blank">systemsafety@TechFak.Uni-Bielefeld.DE</a><br>
Manage your subscription: <a href="https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety" rel="noreferrer" target="_blank">
https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety</a><br>
</blockquote>
</div>
_______________________________________________<br>
The System Safety Mailing List<br>
<a href="mailto:systemsafety@TechFak.Uni-Bielefeld.DE" target="_blank">systemsafety@TechFak.Uni-Bielefeld.DE</a><br>
Manage your subscription: <a href="https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety" target="_blank">https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety</a></div>
</div>
<br>
</div>
</blockquote></div>