<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>
<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:48784199-14B4-4813-9B3A-6988EC795CEF"></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="lineBreakAtBeginningOfMessage">
<div><br>
<div>On May 19, 2026, at 2:14 AM, Les Chambers <les@chambers.com.au> wrote:</div>
<br class="Apple-interchange-newline">
<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 gmail_quote_container">
<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">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>
systemsafety@TechFak.Uni-Bielefeld.DE<br>
Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety</div>
</div>
<br>
</body>
</html>