<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>